You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Costin Leau <co...@gmail.com> on 2007/06/01 15:24:17 UTC
bnd plugin unpack option
Hello everybody,
We are using the maven bnd plugin in a maven project with submodules
and, as reported already, due to the way maven works, the classpath is
assembled incorrectly since the local target/class files is being used
instead of the locally deployed artifact.
I keep making patches around this problem but I was wondering whether
would you consider adding an option for unpacking the created bundle in
the target folder of the owning project.
This way, systems that use modules and the maven plugin do not have to
come with their own, incomplete solution for doing a build.
What do you think?
Cheers,
--
Costin
Re: bnd plugin unpack option
Posted by Stuart McCulloch <st...@jayway.net>.
On 01/06/07, Costin Leau <co...@gmail.com> wrote:
> Stuart McCulloch wrote:
> > On 01/06/07, Costin Leau <co...@gmail.com> wrote:
> >> Hello everybody,
> >>
> >> We are using the maven bnd plugin in a maven project with submodules
> >> and, as reported already, due to the way maven works, the classpath is
> >> assembled incorrectly since the local target/class files is being used
> >> instead of the locally deployed artifact.
> >>
> >> I keep making patches around this problem but I was wondering whether
> >> would you consider adding an option for unpacking the created bundle in
> >> the target folder of the owning project.
> >
> > I use the maven-dependency-plugin to unpack bundles ... adding an
> > option to the bundle-plugin would be neater (less config in the poms)
> > but duplicates functionality from other plugins.
>
> Right - I've tried it and in a module, 2 levels deep it kicks in before
> the bundle is being uploaded and thus has nothing to unpack.
some of the odd/unexpected plugin behaviour could be to do with using
<build><plugins>... in the parent spring-osgi pom to configure defaults.
I've found that using <build><pluginManagement><plugins>... behaves
much better - but means you have to list the plugins in each child pom
(no config/goals info, really just a short list of the plugin ids)
there's an example of this approach at:
https://scm.ops4j.org/repos/ops4j/laboratory/users/stuart/peaberry
the pluginManagement element lets you configure plugins, but not add
them to every sub-build (which could explain why this behaves better).
>
> Not to mention that when using it on over 20 sub-modules (which is the
> case with Spring/OSGi) we have a *lot* of duplication to do. You would
> not believe how much time was wasted because of this.
oh I can :)
spent ages trying out different approaches before I settled on the current
methodology in PaxConstruct (especially wrt. getting things matched up
with Eclipse and other IDEs!)
> I've tried using some sort of 'templating' but the problem is that maven
> applies the template on the declaring pom (the modules parent) as well
> as the children.
I think pluginManagement would avoid this...
>
> Moreover, there is a maven bug which doesn't propagate plugin
> inheritance more then 1 level deep.
>
true - although, it is possible to work around this because child modules
don't actually have to have their containing module as their pom parent.
> >
> >>
> >> This way, systems that use modules and the maven plugin do not have to
> >> come with their own, incomplete solution for doing a build.
> >>
> >> What do you think?
> >>
> >
> > no views either way - not much code required, but could be seen as bloat...
>
> One thing to consider here - I'm suggesting unzipping/unjaring a
> particular archive.
> The dependency maven plugin is quite generic and has plenty of other
> options such as copying, determining the dependencies and so on.
>
sure - as I said, this isn't much work (just playing devil's advocate)
btw, let me know if you want more info on the PaxConstruct approach...
>
> >
> >> Cheers,
> >> --
> >> Costin
> >>
> >
> >
>
>
> --
> Costin
>
--
Cheers, Stuart
Re: Re[2]: bnd plugin unpack option
Posted by Stuart McCulloch <st...@jayway.net>.
On 04/06/07, Peter Kriens <Pe...@aqute.biz> wrote:
> You are sure it is a maven bug and not related to the "current working
> directory". Most of the time, tools/plugins get confused with the
> working directory if the project is not the working directory. I am
> trying to be careful but bnd could have issues there because I almost
> solely use it in single project mode.
>
> If not, is it possible to rewrite the classpath in bnd?
unfortunately this affects compilation of java code (ie. before bnd is involved)
it may be possible to get the maven-bundle-plugin to fixup the classpath but
this would require changes to its plugin lifecycle & could cause side-effects
in other participating plugins, so it isn't a quick fix...
>
> Kind regards,
>
> Peter Kriens
>
>
> CL> Peter Kriens wrote:
> >> I am not sure I understand the bug (I only understand it is unrelated
> >> to bnd), but it is trivial to save the build jar in a directory
> >> instead of jar file. That is, you do not first have to jar it and then
> >> unjar it.
> >>
> >> I guess this allows the packager to do its work?
> >>
> >> Now, before bnd is called, the plugin assembles the classpath from
> >> the maven information. If we get a good overview from the bugs then it
> >> should not be that hard to rewrite the classpath?
> >>
> CL> The problem is maven itself not the plugin or bnd.
> CL> Basically when you use modules and do a full build, then maven uses the
> CL> local classpath of the existing modules (target/classes folder) instead
> CL> of the published artifacts.
> CL> Since the bnd plugin creates only a jar but doesn't unpack any files
> CL> under target/classes (why should it?), maven adds an empty folder to the
> CL> classpath which leads to errors when compiling.
>
> CL> If the modules are ran individually then everything is fine.
> >> Kind regards,
> >>
> >> Peter Kriens
> >>
> >>
> >>
> >> CL> Stuart McCulloch wrote:
> >>>> On 01/06/07, Costin Leau <co...@gmail.com> wrote:
> >>>>> Hello everybody,
> >>>>>
> >>>>> We are using the maven bnd plugin in a maven project with submodules
> >>>>> and, as reported already, due to the way maven works, the classpath is
> >>>>> assembled incorrectly since the local target/class files is being used
> >>>>> instead of the locally deployed artifact.
> >>>>>
> >>>>> I keep making patches around this problem but I was wondering whether
> >>>>> would you consider adding an option for unpacking the created bundle in
> >>>>> the target folder of the owning project.
> >>>> I use the maven-dependency-plugin to unpack bundles ... adding an
> >>>> option to the bundle-plugin would be neater (less config in the poms)
> >>>> but duplicates functionality from other plugins.
> >>
> >> CL> Right - I've tried it and in a module, 2 levels deep it kicks in before
> >> CL> the bundle is being uploaded and thus has nothing to unpack.
> >>
> >> CL> Not to mention that when using it on over 20 sub-modules (which is the
> >> CL> case with Spring/OSGi) we have a *lot* of duplication to do. You would
> >> CL> not believe how much time was wasted because of this.
> >> CL> I've tried using some sort of 'templating' but the problem is that maven
> >> CL> applies the template on the declaring pom (the modules parent) as well
> >> CL> as the children.
> >>
> >> CL> Moreover, there is a maven bug which doesn't propagate plugin
> >> CL> inheritance more then 1 level deep.
> >>
> >>>>> This way, systems that use modules and the maven plugin do not have to
> >>>>> come with their own, incomplete solution for doing a build.
> >>>>>
> >>>>> What do you think?
> >>>>>
> >>>> no views either way - not much code required, but could be seen as bloat...
> >>
> >> CL> One thing to consider here - I'm suggesting unzipping/unjaring a
> >> CL> particular archive.
> >> CL> The dependency maven plugin is quite generic and has plenty of other
> >> CL> options such as copying, determining the dependencies and so on.
> >>
> >>
> >>>>> Cheers,
> >>>>> --
> >>>>> Costin
> >>>>>
> >>>>
> >>
> >>
> >>
> >>
>
>
>
>
> --
> Peter Kriens Tel +33467542167
> 9C, Avenue St. Drézéry AOL,Yahoo: pkriens
> 34160 Beaulieu, France ICQ 255570717
> Skype pkriens Fax +1 8153772599
>
>
--
Cheers, Stuart
Re[2]: bnd plugin unpack option
Posted by Peter Kriens <Pe...@aQute.biz>.
You are sure it is a maven bug and not related to the "current working
directory". Most of the time, tools/plugins get confused with the
working directory if the project is not the working directory. I am
trying to be careful but bnd could have issues there because I almost
solely use it in single project mode.
If not, is it possible to rewrite the classpath in bnd?
Kind regards,
Peter Kriens
CL> Peter Kriens wrote:
>> I am not sure I understand the bug (I only understand it is unrelated
>> to bnd), but it is trivial to save the build jar in a directory
>> instead of jar file. That is, you do not first have to jar it and then
>> unjar it.
>>
>> I guess this allows the packager to do its work?
>>
>> Now, before bnd is called, the plugin assembles the classpath from
>> the maven information. If we get a good overview from the bugs then it
>> should not be that hard to rewrite the classpath?
>>
CL> The problem is maven itself not the plugin or bnd.
CL> Basically when you use modules and do a full build, then maven uses the
CL> local classpath of the existing modules (target/classes folder) instead
CL> of the published artifacts.
CL> Since the bnd plugin creates only a jar but doesn't unpack any files
CL> under target/classes (why should it?), maven adds an empty folder to the
CL> classpath which leads to errors when compiling.
CL> If the modules are ran individually then everything is fine.
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>>
>> CL> Stuart McCulloch wrote:
>>>> On 01/06/07, Costin Leau <co...@gmail.com> wrote:
>>>>> Hello everybody,
>>>>>
>>>>> We are using the maven bnd plugin in a maven project with submodules
>>>>> and, as reported already, due to the way maven works, the classpath is
>>>>> assembled incorrectly since the local target/class files is being used
>>>>> instead of the locally deployed artifact.
>>>>>
>>>>> I keep making patches around this problem but I was wondering whether
>>>>> would you consider adding an option for unpacking the created bundle in
>>>>> the target folder of the owning project.
>>>> I use the maven-dependency-plugin to unpack bundles ... adding an
>>>> option to the bundle-plugin would be neater (less config in the poms)
>>>> but duplicates functionality from other plugins.
>>
>> CL> Right - I've tried it and in a module, 2 levels deep it kicks in before
>> CL> the bundle is being uploaded and thus has nothing to unpack.
>>
>> CL> Not to mention that when using it on over 20 sub-modules (which is the
>> CL> case with Spring/OSGi) we have a *lot* of duplication to do. You would
>> CL> not believe how much time was wasted because of this.
>> CL> I've tried using some sort of 'templating' but the problem is that maven
>> CL> applies the template on the declaring pom (the modules parent) as well
>> CL> as the children.
>>
>> CL> Moreover, there is a maven bug which doesn't propagate plugin
>> CL> inheritance more then 1 level deep.
>>
>>>>> This way, systems that use modules and the maven plugin do not have to
>>>>> come with their own, incomplete solution for doing a build.
>>>>>
>>>>> What do you think?
>>>>>
>>>> no views either way - not much code required, but could be seen as bloat...
>>
>> CL> One thing to consider here - I'm suggesting unzipping/unjaring a
>> CL> particular archive.
>> CL> The dependency maven plugin is quite generic and has plenty of other
>> CL> options such as copying, determining the dependencies and so on.
>>
>>
>>>>> Cheers,
>>>>> --
>>>>> Costin
>>>>>
>>>>
>>
>>
>>
>>
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: bnd plugin unpack option
Posted by Costin Leau <co...@gmail.com>.
Peter Kriens wrote:
> I am not sure I understand the bug (I only understand it is unrelated
> to bnd), but it is trivial to save the build jar in a directory
> instead of jar file. That is, you do not first have to jar it and then
> unjar it.
>
> I guess this allows the packager to do its work?
>
> Now, before bnd is called, the plugin assembles the classpath from
> the maven information. If we get a good overview from the bugs then it
> should not be that hard to rewrite the classpath?
>
The problem is maven itself not the plugin or bnd.
Basically when you use modules and do a full build, then maven uses the
local classpath of the existing modules (target/classes folder) instead
of the published artifacts.
Since the bnd plugin creates only a jar but doesn't unpack any files
under target/classes (why should it?), maven adds an empty folder to the
classpath which leads to errors when compiling.
If the modules are ran individually then everything is fine.
> Kind regards,
>
> Peter Kriens
>
>
>
> CL> Stuart McCulloch wrote:
>>> On 01/06/07, Costin Leau <co...@gmail.com> wrote:
>>>> Hello everybody,
>>>>
>>>> We are using the maven bnd plugin in a maven project with submodules
>>>> and, as reported already, due to the way maven works, the classpath is
>>>> assembled incorrectly since the local target/class files is being used
>>>> instead of the locally deployed artifact.
>>>>
>>>> I keep making patches around this problem but I was wondering whether
>>>> would you consider adding an option for unpacking the created bundle in
>>>> the target folder of the owning project.
>>> I use the maven-dependency-plugin to unpack bundles ... adding an
>>> option to the bundle-plugin would be neater (less config in the poms)
>>> but duplicates functionality from other plugins.
>
> CL> Right - I've tried it and in a module, 2 levels deep it kicks in before
> CL> the bundle is being uploaded and thus has nothing to unpack.
>
> CL> Not to mention that when using it on over 20 sub-modules (which is the
> CL> case with Spring/OSGi) we have a *lot* of duplication to do. You would
> CL> not believe how much time was wasted because of this.
> CL> I've tried using some sort of 'templating' but the problem is that maven
> CL> applies the template on the declaring pom (the modules parent) as well
> CL> as the children.
>
> CL> Moreover, there is a maven bug which doesn't propagate plugin
> CL> inheritance more then 1 level deep.
>
>>>> This way, systems that use modules and the maven plugin do not have to
>>>> come with their own, incomplete solution for doing a build.
>>>>
>>>> What do you think?
>>>>
>>> no views either way - not much code required, but could be seen as bloat...
>
> CL> One thing to consider here - I'm suggesting unzipping/unjaring a
> CL> particular archive.
> CL> The dependency maven plugin is quite generic and has plenty of other
> CL> options such as copying, determining the dependencies and so on.
>
>
>>>> Cheers,
>>>> --
>>>> Costin
>>>>
>>>
>
>
>
>
--
Costin
Re[2]: bnd plugin unpack option
Posted by Peter Kriens <Pe...@aQute.biz>.
I am not sure I understand the bug (I only understand it is unrelated
to bnd), but it is trivial to save the build jar in a directory
instead of jar file. That is, you do not first have to jar it and then
unjar it.
I guess this allows the packager to do its work?
Now, before bnd is called, the plugin assembles the classpath from
the maven information. If we get a good overview from the bugs then it
should not be that hard to rewrite the classpath?
Kind regards,
Peter Kriens
CL> Stuart McCulloch wrote:
>> On 01/06/07, Costin Leau <co...@gmail.com> wrote:
>>> Hello everybody,
>>>
>>> We are using the maven bnd plugin in a maven project with submodules
>>> and, as reported already, due to the way maven works, the classpath is
>>> assembled incorrectly since the local target/class files is being used
>>> instead of the locally deployed artifact.
>>>
>>> I keep making patches around this problem but I was wondering whether
>>> would you consider adding an option for unpacking the created bundle in
>>> the target folder of the owning project.
>>
>> I use the maven-dependency-plugin to unpack bundles ... adding an
>> option to the bundle-plugin would be neater (less config in the poms)
>> but duplicates functionality from other plugins.
CL> Right - I've tried it and in a module, 2 levels deep it kicks in before
CL> the bundle is being uploaded and thus has nothing to unpack.
CL> Not to mention that when using it on over 20 sub-modules (which is the
CL> case with Spring/OSGi) we have a *lot* of duplication to do. You would
CL> not believe how much time was wasted because of this.
CL> I've tried using some sort of 'templating' but the problem is that maven
CL> applies the template on the declaring pom (the modules parent) as well
CL> as the children.
CL> Moreover, there is a maven bug which doesn't propagate plugin
CL> inheritance more then 1 level deep.
>>
>>>
>>> This way, systems that use modules and the maven plugin do not have to
>>> come with their own, incomplete solution for doing a build.
>>>
>>> What do you think?
>>>
>>
>> no views either way - not much code required, but could be seen as bloat...
CL> One thing to consider here - I'm suggesting unzipping/unjaring a
CL> particular archive.
CL> The dependency maven plugin is quite generic and has plenty of other
CL> options such as copying, determining the dependencies and so on.
>>
>>> Cheers,
>>> --
>>> Costin
>>>
>>
>>
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: bnd plugin unpack option
Posted by Costin Leau <co...@gmail.com>.
Stuart McCulloch wrote:
> On 01/06/07, Costin Leau <co...@gmail.com> wrote:
>> Hello everybody,
>>
>> We are using the maven bnd plugin in a maven project with submodules
>> and, as reported already, due to the way maven works, the classpath is
>> assembled incorrectly since the local target/class files is being used
>> instead of the locally deployed artifact.
>>
>> I keep making patches around this problem but I was wondering whether
>> would you consider adding an option for unpacking the created bundle in
>> the target folder of the owning project.
>
> I use the maven-dependency-plugin to unpack bundles ... adding an
> option to the bundle-plugin would be neater (less config in the poms)
> but duplicates functionality from other plugins.
Right - I've tried it and in a module, 2 levels deep it kicks in before
the bundle is being uploaded and thus has nothing to unpack.
Not to mention that when using it on over 20 sub-modules (which is the
case with Spring/OSGi) we have a *lot* of duplication to do. You would
not believe how much time was wasted because of this.
I've tried using some sort of 'templating' but the problem is that maven
applies the template on the declaring pom (the modules parent) as well
as the children.
Moreover, there is a maven bug which doesn't propagate plugin
inheritance more then 1 level deep.
>
>>
>> This way, systems that use modules and the maven plugin do not have to
>> come with their own, incomplete solution for doing a build.
>>
>> What do you think?
>>
>
> no views either way - not much code required, but could be seen as bloat...
One thing to consider here - I'm suggesting unzipping/unjaring a
particular archive.
The dependency maven plugin is quite generic and has plenty of other
options such as copying, determining the dependencies and so on.
>
>> Cheers,
>> --
>> Costin
>>
>
>
--
Costin
Re: bnd plugin unpack option
Posted by Stuart McCulloch <st...@jayway.net>.
On 01/06/07, Costin Leau <co...@gmail.com> wrote:
> Hello everybody,
>
> We are using the maven bnd plugin in a maven project with submodules
> and, as reported already, due to the way maven works, the classpath is
> assembled incorrectly since the local target/class files is being used
> instead of the locally deployed artifact.
>
> I keep making patches around this problem but I was wondering whether
> would you consider adding an option for unpacking the created bundle in
> the target folder of the owning project.
I use the maven-dependency-plugin to unpack bundles ... adding an
option to the bundle-plugin would be neater (less config in the poms)
but duplicates functionality from other plugins.
>
> This way, systems that use modules and the maven plugin do not have to
> come with their own, incomplete solution for doing a build.
>
> What do you think?
>
no views either way - not much code required, but could be seen as bloat...
> Cheers,
> --
> Costin
>
--
Cheers, Stuart