felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stuart McCulloch" <stuart.mccull...@jayway.net>
Subject Re: bnd plugin unpack option
Date Sat, 02 Jun 2007 05:31:27 GMT
On 01/06/07, Costin Leau <costin.leau@gmail.com> wrote:
> Stuart McCulloch wrote:
> > On 01/06/07, Costin Leau <costin.leau@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:


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

View raw message