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/
