Yay! Thx for applying! On Dec 7, 2007 2:10 AM, Stuart McCulloch <[EMAIL PROTECTED]> wrote: > On 07/12/2007, 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 > > ;-) > > > btw, I'm planning on tweaking the patch, as it currently ignores the > manifestLocation option > when the unpack option is enabled, which isn't correct - when people use > Eclipse/PDE they'd > want the manifest at the project root, even with unpacking enabled... just a > minor thing > > > 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, Stuart >
-- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com
