'dependency reduced pom'

[Benson Margulies <be...@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.

Re: 'dependency reduced pom'

[Benson Margulies <be...@basistech.com>]

On Sat, Aug 15, 2015 at 12:46 PM, David Jencks
<da...@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 <be...@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
>> <da...@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 <be...@basistech.com> wrote:
>>>>
>>>> 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.
>>>
>

Re: 'dependency reduced pom'

[David Jencks <da...@yahoo.com.INVALID>]

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?

thanks
david jencks

> On Aug 15, 2015, at 12:30 PM, Benson Margulies <be...@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
> <da...@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 <be...@basistech.com> wrote:
>>> 
>>> 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.
>> 

Re: 'dependency reduced pom'

[Benson Margulies <be...@basistech.com>]

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
<da...@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 <be...@basistech.com> wrote:
>>
>> 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.
>

Re: 'dependency reduced pom'

[David Jencks <da...@yahoo.com.INVALID>]

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 <be...@basistech.com> wrote:
> 
> 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.