felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Bartlett <njbartl...@gmail.com>
Subject Re: Bundle dependency management
Date Fri, 12 Dec 2014 14:04:41 GMT
On Fri, Dec 12, 2014 at 10:19 AM, Christian Schneider <
chris@die-schneider.net> wrote:
>
> I also think the impedance mismatch between maven and osgi is a big
> problem when doing OSGi work.
>
> What I do not like though in the bndtools projects I saw till now is that
> they all seem to contain a complete set of jars inside the checked in
> source.
> I know they use this to populate the obr (or similar) repository they then
> work with.
>
> This kind of setting up your environment reminds me a lot of the pre maven
> era and I think it is a step back. Is there some better solution to this?
> I would at least want all my jars to come from maven so they do not
> pollute git.
>


This is just one way of configuring your workspace. We have a flexible
repository model that can resolve dependencies from remote repositories or
checked-in JARs. We tend to use the checked-in JAR approach for certain
demo or training environments (e.g. at conferences) where it can be risky
to rely on a workable internet connection.


>
> A similar thing applies for most of the eclipse projects. Most of them
> seem to use tycho even when they are completely server side. In the end
> they provide their jars in eclipse features that contain the whole wars.
> Most of the time they also do not seem to publish to maven central. So in
> the end you have a mixture of dependencies that are only in maven and some
> that are only in eclipse update sites. This is a really bad situation.
>
> Christian
>
>
> On 12.12.2014 04:40, David Jencks wrote:
>
>> Hopefully you are not using any require-bundle headers.
>>
>> So you can think in terms of package requirements rather than bundle
>> dependencies.  OBR is pretty much the solution to this, but AFAIK there is
>> no reasonable way to automate figuring out what set of bundles should be in
>> your repository.  IIRC some versions of nexus (maybe all by now) can
>> generate an xml file for obr, but I don't think running obr against maven
>> central is likely to produce results you are happy with.
>>
>> After being a maven fanatic for many years I now think the impedance
>> mismatches between maven and osgi are pretty large and given a free hand
>> with a project would probably use a gradle + bndtools build with a local
>> file system repository (generally under "cnf" in these builds IIUC for
>> reasons I don't know).
>>
>> hopefully I haven't misunderstood your question too much...
>> david jencks
>>
>>
>> On Dec 11, 2014, at 12:38 PM, Benson Margulies <benson@basistech.com>
>> wrote:
>>
>>  So, here I am, setting up an application that embeds Felix. I need it
>>> to contain a certain collection of bundles -- and then some
>>> dependencies of those bundles.
>>>
>>> Plain-old-maven can't help very much with managing those dependencies,
>>> since it can only deal with one version per Group/Artifact, and I
>>> expect to have cases where we need more than one major version of some
>>> things (e.g. Guava).
>>>
>>> is there a commonly-used solution to all of this? I'm contemplating
>>> writing a Maven plugin, but I would like to avoid recreating the
>>> wheel.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message