karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <ben...@basistech.com>
Subject Re: transitive dependencies of feature descriptors
Date Fri, 05 Aug 2016 13:03:58 GMT
I want to use make the _non_-OSGi dependences 'provided', so that I can use
 <ignoreScopeProvided>true</ignoreScopeProvided> to the plugin to avoid
having them show up again as wrap:. So I have to keep the OSGi dependencies
as 'compile'. Then, when Guice or Servicemix or Antlr has a non-OSGi
dependency, I am now re-declaring it at top-level as provided, to keep it
out of the mixture. The pom is quite lengthy.

Then I have one last oddity: think of the above as project 'A'. Then, when
project 'B' declares a dependency on the feature descriptor of project 'A',
and aggregates its feature, the OSGi dependencies of B wind up in the
feature.xml twice: once in A and once in B. THis is harmless but annoying.

On Fri, Aug 5, 2016 at 8:58 AM, Jean-Baptiste Onofré <jb@nanthrax.net>
wrote:

> OK I understand better now. What about changing the scope of the bundle
> dependency ?
>
> Regards
> JB
> On Fri, Aug 05, 2016 at 2:34 PM, Benson Margulies <benson@basistech.com>
> wrote:
>
>
>
> On Fri, Aug 5, 2016 at 8:32 AM, Jean-Baptiste Onofré <jb@nanthrax.net>
> wrote:
>
>> You mean that you use the karaf-maven-plugin to generate the features.xml
>> ?
>>
>
> JB,
>
> Yes, I always use the plugin.
> Regards, benson
>
>
>> Regards
>> JB
>>
>> On 08/05/2016 02:28 PM, Benson Margulies wrote:
>>
>>> JB,
>>>
>>> The jar files incorporated in the uber jar show up in the dependency
>>> graph and thus reappear in as 'wrap:' bundles in features.
>>>
>>> If project X declares a dependency on feature F, then the dependencies
>>> of feature F are considered as bundles in project X's feature, because
>>> they are part of project X's overall dependency graph. the
>>> karaf-maven-plugin does not filter them out, even though F is accounted
>>> for as an aggregated feature.
>>>
>>> Regards,
>>> benson
>>>
>>>
>>> On Fri, Aug 5, 2016 at 8:09 AM, Jean-Baptiste Onofré <jb@nanthrax.net
>>> <mailto:jb@nanthrax.net>> wrote:
>>>
>>> Hi Benson,
>>>
>>> honestly, I don't understand your point ;)
>>>
>>> You have an "uber" bundle containing packages, and this bundle is in
>>> a feature.
>>>
>>> This feature can be used as an inner feature.
>>>
>>> So what's the point ?
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 08/05/2016 02:03 PM, Benson Margulies wrote:
>>>
>>> Folks, I wonder if someone else has found a way out of this.
>>>
>>> Consider a project that builds an OSGi bundle by aggregating some
>>> non-OSGi jar Maven dependencies. Those dependencies are in the
>>> dependency tree of the resulting bundle.
>>>
>>> Now, consider what happens if you generate a feature to contain that
>>> bundle. You can carefully exclude artifactIds to ensure that these
>>> embedded jars do not show up in the feature.xml as 'wrap' bundles.
>>>
>>> However, there are still in the dependency graph of the feature
>>> itself.
>>>
>>> So, when you write a dependency _on the feature_ to incorporate that
>>> feature in a larger system, now the non-OSGi bundles are back in the
>>> picture. You then have to write Maven <exclusions> for them all
>>> over again.
>>>
>>> If I wrote a patch to the karaf-maven-plugin to exclude non-feature
>>> dependencies of features, would some committer commit it?
>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org <mailto:jbonofre@apache.org>
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>

Mime
View raw message