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 <[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
