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 <[email protected]> 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 > <[email protected]> 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 <[email protected]> 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. >>
