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
