You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2007/12/06 16:51:07 UTC
Problem with the bundle plugin (and patch)
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. 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 ?
Thanks!
[1] https://issues.apache.org/jira/browse/FELIX-433
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Problem with the bundle plugin (and patch)
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Yay! Thx for applying!
On Dec 7, 2007 2:10 AM, Stuart McCulloch <st...@jayway.net> wrote:
> On 07/12/2007, Guillaume Nodet <gn...@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 <st...@jayway.net>
> > wrote:
> >
> > > On 06/12/2007, Guillaume Nodet <gn...@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
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
Re: Problem with the bundle plugin (and patch)
Posted by Stuart McCulloch <st...@jayway.net>.
On 07/12/2007, Guillaume Nodet <gn...@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 <st...@jayway.net>
> wrote:
>
> > On 06/12/2007, Guillaume Nodet <gn...@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
Re: Problem with the bundle plugin (and patch)
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <gn...@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
> ;-)
>
>
> On Dec 7, 2007 7:59 AM, Stuart McCulloch <st...@jayway.net>
> wrote:
>
> > On 06/12/2007, Guillaume Nodet <gn...@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,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Problem with the bundle plugin (and patch)
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <st...@jayway.net>
wrote:
> On 06/12/2007, Guillaume Nodet <gn...@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/
Re: Problem with the bundle plugin (and patch)
Posted by Stuart McCulloch <st...@jayway.net>.
On 06/12/2007, Guillaume Nodet <gn...@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
Re: Problem with the bundle plugin (and patch)
Posted by Stuart McCulloch <st...@jayway.net>.
>
> On 08/12/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> > >
> > > I have a problem when using this patch in a reactor.
> > > It seems that the jars are sometimes extracted at the root instead of
> > > ${basedir}/target/
> > > I will investigate further.
> >
> >
> found the problem - if you don't have any source code in your project
> Maven will set the output directory to null, which the plexus unarchiver
> assumes means the current directory... it's a simple fix
>
actually it's even more bizarre - the output directory is not null and is
the
correct directory, but because it doesn't exist yet the unarchiver (for some
unknown reason) decides to use 'null' as the path, ie. the current folder!
so the fix is to always use mkdirs before unpacking...
--
Cheers, Stuart
Re: Problem with the bundle plugin (and patch)
Posted by Stuart McCulloch <st...@jayway.net>.
On 08/12/2007, Stuart McCulloch <st...@jayway.net> wrote:
>
> On 08/12/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> > I have a problem when using this patch in a reactor.
> > It seems that the jars are sometimes extracted at the root instead of
> > ${basedir}/target/
> > I will investigate further.
>
>
found the problem - if you don't have any source code in your project
Maven will set the output directory to null, which the plexus unarchiver
assumes means the current directory... it's a simple fix
the patch uses the project output directory (ie. target/classes) - but if
> you're
> running the plugin in certain modes (ie. maybe forked lifecycle) then it
> could
> be picking up the 'initiating' project rather than the 'executed' project
>
> I've seen this happen with other settings, so I think I know the fix - but
> if you
> can send me a simple pom that recreates the issue, that would be great :)
>
> On Dec 6, 2007 4:51 PM, 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. 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 ?
> > > Thanks!
> > >
> > > [1] https://issues.apache.org/jira/browse/FELIX-433
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > > ------------------------
> > > Blog: http://gnodet.blogspot.com/
> >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> >
>
>
>
> --
> Cheers, Stuart
--
Cheers, Stuart
Re: Problem with the bundle plugin (and patch)
Posted by Guillaume Nodet <gn...@gmail.com>.
I experience the problem using the following pom:
http://svn.apache.org/repos/asf/servicemix/branches/servicemix-4.0/runtime/pom.xml
On Dec 8, 2007 11:23 AM, Stuart McCulloch <st...@jayway.net>
wrote:
> On 08/12/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> > I have a problem when using this patch in a reactor.
> > It seems that the jars are sometimes extracted at the root instead of
> > ${basedir}/target/
> > I will investigate further.
>
>
> the patch uses the project output directory (ie. target/classes) - but if
> you're
> running the plugin in certain modes (ie. maybe forked lifecycle) then it
> could
> be picking up the 'initiating' project rather than the 'executed' project
>
> I've seen this happen with other settings, so I think I know the fix - but
> if you
> can send me a simple pom that recreates the issue, that would be great :)
>
> On Dec 6, 2007 4:51 PM, Guillaume Nodet <gn...@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. 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 ?
> > > Thanks!
> > >
> > > [1] https://issues.apache.org/jira/browse/FELIX-433
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > > ------------------------
> > > Blog: http://gnodet.blogspot.com/
> >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> >
>
>
>
> --
> Cheers, Stuart
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Problem with the bundle plugin (and patch)
Posted by Stuart McCulloch <st...@jayway.net>.
On 08/12/2007, Guillaume Nodet <gn...@gmail.com> wrote:
>
> I have a problem when using this patch in a reactor.
> It seems that the jars are sometimes extracted at the root instead of
> ${basedir}/target/
> I will investigate further.
the patch uses the project output directory (ie. target/classes) - but if
you're
running the plugin in certain modes (ie. maybe forked lifecycle) then it
could
be picking up the 'initiating' project rather than the 'executed' project
I've seen this happen with other settings, so I think I know the fix - but
if you
can send me a simple pom that recreates the issue, that would be great :)
On Dec 6, 2007 4:51 PM, Guillaume Nodet <gn...@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. 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 ?
> > Thanks!
> >
> > [1] https://issues.apache.org/jira/browse/FELIX-433
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
--
Cheers, Stuart
Re: Problem with the bundle plugin (and patch)
Posted by Guillaume Nodet <gn...@gmail.com>.
Wow, you're fast :-) Thanks a lot Stuart!
On Dec 8, 2007 12:36 PM, Stuart McCulloch <st...@jayway.net>
wrote:
> On 08/12/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> > I have a problem when using this patch in a reactor.
> > It seems that the jars are sometimes extracted at the root instead of
> > ${basedir}/target/
> > I will investigate further.
>
>
> FYI, fix has been committed (r602449) and a new snapshot has been deployed
> -
> HTH
>
> On Dec 6, 2007 4:51 PM, Guillaume Nodet <gn...@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. 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 ?
> > > Thanks!
> > >
> > > [1] https://issues.apache.org/jira/browse/FELIX-433
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > > ------------------------
> > > Blog: http://gnodet.blogspot.com/
> >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> >
>
>
>
> --
> Cheers, Stuart
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Problem with the bundle plugin (and patch)
Posted by Stuart McCulloch <st...@jayway.net>.
On 08/12/2007, Guillaume Nodet <gn...@gmail.com> wrote:
>
> I have a problem when using this patch in a reactor.
> It seems that the jars are sometimes extracted at the root instead of
> ${basedir}/target/
> I will investigate further.
FYI, fix has been committed (r602449) and a new snapshot has been deployed -
HTH
On Dec 6, 2007 4:51 PM, Guillaume Nodet <gn...@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. 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 ?
> > Thanks!
> >
> > [1] https://issues.apache.org/jira/browse/FELIX-433
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
--
Cheers, Stuart
Re: Problem with the bundle plugin (and patch)
Posted by Guillaume Nodet <gn...@gmail.com>.
I have a problem when using this patch in a reactor.
It seems that the jars are sometimes extracted at the root instead of
${basedir}/target/
I will investigate further.
On Dec 6, 2007 4:51 PM, Guillaume Nodet <gn...@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. 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 ?
> Thanks!
>
> [1] https://issues.apache.org/jira/browse/FELIX-433
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/