On 01/06/07, Costin Leau <[EMAIL PROTECTED]> wrote:
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.
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
