On 04/06/07, Peter Kriens <[EMAIL PROTECTED]> 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 <[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
--
Cheers, Stuart
