Note that the benefit of adding that to the maven-bundle-plugin is that you can configure it on the top pom and you'd not have to add a new plugin / config in each sub module (as it would be the case when using the dependency plugin), so while I agree this is a workaround for a known maven bug, i think the patch is still handy.
On Dec 7, 2007 8:05 AM, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > Yeah, I understand the problem. > FYI, the patch Hiram attached adds an optional flag to unpack the artifact > (which is set to false by default to keep the existing behavior), so the > patch is quite harmless and it seems this is want you are just talking about > ;-) > > > On Dec 7, 2007 7:59 AM, Stuart McCulloch <[EMAIL PROTECTED]> > wrote: > > > On 06/12/2007, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > > > > > While working on the ServiceMix project, Hiram found a bug and raise a > > > JIRA > > > with an attached patch [1]. > > > The problem is that in a reactor build (multiproject build), maven > > uses > > > the > > > ./target/classes folder of dependant modules and add those in the > > > classpath. > > > > > > yes, this is actually a known bug with the core Maven code, specifically > > with the > > MavenProject.java class - it always uses 'target/classes' for projects > > in > > the same > > reactor rather than the final artifact. > > > > ( see the Felix mail archives for previous discussions on this topic ) > > > > unfortunately because MavenProject.java is a core class, it's not easy > > to > > patch > > or workaround this behaviour - so what people usually do is use the > > dependency > > plugin to unpack the bundle after it's been built. > > > > the maven-pax-plugin (as used in Pax-Construct) provides another > > solution by > > extending the Maven compiler mojo so it uses the original bundle, which > > means > > no unpacking is required (it also handles compiling against embedded > > entries). > > > > This causes a problem, because the bundle plugin does not > > > extract the classes in that folder, which cause the classpath to not > > > contain > > > the neeed classes. > > > Can someone review the patch and apply it please ? > > > > > > so far I've been resisting the urge to add an unpack feature to the > > bundle-plugin > > because the same result is possible by adding the > > maven-dependency-plugin to > > the pom, and it's often better to combine plugins in the pom than have a > > plugin > > grow into a huge 'does-everything-you-ever-need' jar with duplicated > > source. > > > > anyway, I'll take a look and think about making this an optional feature > > - > > because > > some folks may not want the extra cost of unpacking the bundle, or might > > want > > the target/classes directory kept as-is (ie. not replaced with the > > bundle > > contents) > > > > Thanks! > > > > > > [1] https://issues.apache.org/jira/browse/FELIX-433 > > > > > > -- > > > Cheers, > > > Guillaume Nodet > > > ------------------------ > > > Blog: http://gnodet.blogspot.com/ > > > > > > > > > > > -- > > Cheers, Stuart > > > > > > -- > > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
