felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <ben...@basistech.com>
Subject Re: 'dependency reduced pom'
Date Sat, 15 Aug 2015 16:58:12 GMT
On Sat, Aug 15, 2015 at 12:46 PM, David Jencks
<david_jencks@yahoo.com.invalid> wrote:
> Ah, I didn’t realize you were talking about fixing the maven-bundle-plugin rather than
individual felix projects.
> It’s been a long time…. can’t you just mark the included dependencies “provided”
and the karaf tooling will come up with something appropriate?

'provided' turns out to have unexpected consequences for the
maven-failsafe-plugin. So, yea, you _can_, but there are some issues.

> thanks
> david jencks
>> On Aug 15, 2015, at 12:30 PM, Benson Margulies <benson@basistech.com> wrote:
>> The functionality of the maven-bundle-plugin has some points of
>> comparison to the maven-shade-plugin. The shade plugin can be asked to
>> combine multiple artifacts into one big artifact; when you do that,
>> the default is to publish a pom that reflects that some of the
>> dependencies are now included in the resulting artifact by removing
>> them from the the published pom -- the dependency-reduced pom. For
>> example, if you have a dependency on (e.g.) com.google.guava:guava,
>> and you tell shade to incorporate it into your artifact, the d-r-p
>> will not include guava.
>> When you use Embed-Dependencies in the bundle plugin, you are doing
>> something comparable. If you 'inline' them, you are doing something,
>> well, identical, in that the embedded content is now available for
>> both OSGi and non-OSGi consumers.
>> (I'm not in a position to consider wandering from Maven to Gradle, so
>> my focus is on the Maven universe.)
>> The scenario that hit me was this:
>> 1. I have a pom for a bundle that uses Embed-Dependencies to pull in
>> about 12 non-OSGi jars.
>> 2. I used the result as part of a Karaf feature
>> 3. I had to exclude all those embedded jars, one-by-one, from the
>> Karaf feature, to avoid having them all show up as 'wrapped' bundles.
>> So, I was thinking, wouldn't it be handy if I could choose to tell the
>> maven-bundle-plugin to act like the maven-shade-plugin. For this to be
>> fully-useful, the commonly-used 'depends' plugin (that produces
>> metadata read by Karaf rather than reading the real POM) would have to
>> sucessfully consume the 'reduced' version.
>> On Sat, Aug 15, 2015 at 12:23 PM, David Jencks
>> <david_jencks@yahoo.com.invalid> wrote:
>>> I certainly haven’t rejected the idea because I don’t know what dependency-reduced
poms are.  I have no problem with the effect you describe :-)
>>> Note that some parts of felix are trying to move to gradle/bndtools based builds
(dependency manager and scr at least) I’m not familiar with where the poms come from in
those projects…. but you might want to look at other ones first.
>>> thanks
>>> david jencks
>>>> On Aug 15, 2015, at 12:15 PM, Benson Margulies <benson@basistech.com>
>>>> Has there been previous consideration of giving the
>>>> maven-bundle-plugin the ability to make a dependency-reduced-pom to
>>>> reflect embedded dependencies? When using the Karaf tooling that looks
>>>> at Maven dependencies, the presence of non-bundle dependencies (that
>>>> have been embedded) leads to unwanted 'wrap' bundles.
>>>> I would take a run at this unless it's been considers and rejected as a concept.

View raw message