felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stuart McCulloch" <stuart.mccull...@jayway.net>
Subject Re: Problem with the bundle plugin (and patch)
Date Fri, 07 Dec 2007 07:10:54 GMT
On 07/12/2007, Guillaume Nodet <gnodet@gmail.com> 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 <stuart.mcculloch@jayway.net>
> wrote:
>
> > On 06/12/2007, Guillaume Nodet <gnodet@gmail.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message