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 <[EMAIL PROTECTED]> 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
