On Sat, Aug 15, 2015 at 12:46 PM, David Jencks <[email protected]> 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 <[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. >>> >
