Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: 'dependency reduced pom'
From: David Jencks <david_jencks@yahoo.com.INVALID>
In-Reply-To: 
 <CALm0H57yGd3xePyhReNEo2g5Omg0u5Mvx8WpzWp2vXjUkmtCKw@mail.gmail.com>
Date: Sat, 15 Aug 2015 12:46:50 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <37822E7F-D5F9-49AC-9F9B-B22F9231FA1D@yahoo.com>
References: 
 <CALm0H57rMXBrB-TqrFfCTG=RoeXhhLu5_c8Fmq76OTMfxhVJOw@mail.gmail.com>
 <157E17C6-6ABF-4087-8302-23E68ED89F42@yahoo.com>
 <CALm0H57yGd3xePyhReNEo2g5Omg0u5Mvx8WpzWp2vXjUkmtCKw@mail.gmail.com>
To: dev@felix.apache.org

Ah, I didn=E2=80=99t realize you were talking about fixing the =
maven-bundle-plugin rather than individual felix projects.

It=E2=80=99s been a long time=E2=80=A6. can=E2=80=99t you just mark the =
included dependencies =E2=80=9Cprovided=E2=80=9D and the karaf tooling =
will come up with something appropriate?

thanks
david jencks

> On Aug 15, 2015, at 12:30 PM, Benson Margulies <benson@basistech.com> =
wrote:
>=20
> 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.
>=20
> 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.
>=20
> (I'm not in a position to consider wandering from Maven to Gradle, so
> my focus is on the Maven universe.)
>=20
> The scenario that hit me was this:
>=20
> 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.
>=20
> 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.
>=20
>=20
>=20
> On Sat, Aug 15, 2015 at 12:23 PM, David Jencks
> <david_jencks@yahoo.com.invalid> wrote:
>> I certainly haven=E2=80=99t rejected the idea because I don=E2=80=99t =
know what dependency-reduced poms are.  I have no problem with the =
effect you describe :-)
>>=20
>> Note that some parts of felix are trying to move to gradle/bndtools =
based builds (dependency manager and scr at least) I=E2=80=99m not =
familiar with where the poms come from in those projects=E2=80=A6. but =
you might want to look at other ones first.
>>=20
>> thanks
>> david jencks
>>=20
>>> On Aug 15, 2015, at 12:15 PM, Benson Margulies =
<benson@basistech.com> wrote:
>>>=20
>>> 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.
>>>=20
>>> I would take a run at this unless it's been considers and rejected =
as a concept.
>>=20