Multi-project build is unusable

[Carsten Ziegeler <cz...@apache.org>]

Hi,

I just discovered that our multi-project build is unusable. The problem 
seems to be that we use different versions of the same plugin throughout 
our code base. When doing a multi project build (like using the 
build.xml), only one version of the plugin is used for the whole build - 
resulting in corrupt artifacts in the end.
The main problem atm is the maven-bundle-plugin; some modules use 1.0.0 
while others require 1.1.0-SNAPSHOT; it seems that at least on my 
machine 1.0.0 is used everywhere.

I think that this is a known problem of m2 - and I don't see a good 
solution for this. Using different versions of plugins in different 
modules makes sense as we have different release cycles (well at least 
that's the plan). So the only working solution right now seems to be to 
build module by module separately.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Multi-project build is unusable

[Herko ter Horst <he...@terhorst.net>]

> I think the problem might be that some of the plugins are in the same 
> project hierarchy as where they are used. It might make sense to put 
> those plugins in a different (part of the) hierarchy.

PS. I think the underlying cause is the current repository/module layout 
that lumps everything together and then expects Maven profiles in the 
parent pom to provide separation. IMO this is confusing.

Herko

Re: Multi-project build is unusable

[Stuart McCulloch <st...@jayway.net>]

On 08/01/2008, Herko ter Horst <he...@terhorst.net> wrote:
>
>
> > that's already done by using profiles - the bundleplugin is built
> separate
> > to the projects that use it
>
> Ok, then maybe pluginManagement should be done per profile as well
> (don't know if that's possible?).
>
> Regardless, I think the current parent pom is starting to show "God
> object(*)" symptoms... It might be wise to create a deeper hierachy (or
> separate parallel hierarchies) so each of the current profiles can get
> their own parent pom (each of which can have a shared parent which is
> essentially a significantly reduced version of the current parent).


true, we could separate the current parent pom into
several poms which inherit from the parent, such as:

   trunk/poms/pom.xml
   trunk/poms/bundle/pom.xml
   trunk/poms/plugins/pom.xml
   ...etc...

and use the appropriate parent in each sub-project
- the ant script could then call each parent to build
the various modules, rather than use profiles

but we'd like to keep the main sub-project tree flat
where possible (ie. no deep nesting of sub-projects)

Herko
>
> (*) http://en.wikipedia.org/wiki/God_object
>



-- 
Cheers, Stuart

Re: Multi-project build is unusable

[Herko ter Horst <he...@terhorst.net>]

> that's already done by using profiles - the bundleplugin is built separate
> to the projects that use it

Ok, then maybe pluginManagement should be done per profile as well 
(don't know if that's possible?).

Regardless, I think the current parent pom is starting to show "God 
object(*)" symptoms... It might be wise to create a deeper hierachy (or 
separate parallel hierarchies) so each of the current profiles can get 
their own parent pom (each of which can have a shared parent which is 
essentially a significantly reduced version of the current parent).

Herko

(*) http://en.wikipedia.org/wiki/God_object

Re: Multi-project build is unusable

[Stuart McCulloch <st...@jayway.net>]

On 07/01/2008, Herko ter Horst <he...@terhorst.net> wrote:
>
>
> > To avoid circular dependencies and to be able to use a newer version of
> > the bundleplugin in the modules without always releasing the parent pom.
> >
> > While it seems to be a nice idea to put all versions into the parent
> > pom, I'm coming more and more to the opinion that this is a bad idea if
> > your project consists of several modules that are released independently
> > from each other.
>
> I think the problem might be that some of the plugins are in the same
> project hierarchy as where they are used. It might make sense to put
> those plugins in a different (part of the) hierarchy.


that's already done by using profiles - the bundleplugin is built separate
to the projects that use it

Herko
>



-- 
Cheers, Stuart

Re: Multi-project build is unusable

[Herko ter Horst <he...@terhorst.net>]

> To avoid circular dependencies and to be able to use a newer version of 
> the bundleplugin in the modules without always releasing the parent pom.
> 
> While it seems to be a nice idea to put all versions into the parent 
> pom, I'm coming more and more to the opinion that this is a bad idea if 
> your project consists of several modules that are released independently 
> from each other.

I think the problem might be that some of the plugins are in the same 
project hierarchy as where they are used. It might make sense to put 
those plugins in a different (part of the) hierarchy.

Herko

Re: Multi-project build is unusable

[Carsten Ziegeler <cz...@apache.org>]

Herko ter Horst wrote:
> 
>> I think that this is a known problem of m2 - and I don't see a good 
>> solution for this. Using different versions of plugins in different 
>> modules makes sense as we have different release cycles (well at least 
>> that's the plan). So the only working solution right now seems to be 
>> to build module by module separately.
> 
> I was about to suggest using the parent pom to specify the plugin 
> version, but I see this is already done... although the 
> maven-bundle-plugin is commented out right now.
> 
> Any idea why?
> 
To avoid circular dependencies and to be able to use a newer version of 
the bundleplugin in the modules without always releasing the parent pom.

While it seems to be a nice idea to put all versions into the parent 
pom, I'm coming more and more to the opinion that this is a bad idea if 
your project consists of several modules that are released independently 
from each other.

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Multi-project build is unusable

[Herko ter Horst <he...@terhorst.net>]

> I think that this is a known problem of m2 - and I don't see a good 
> solution for this. Using different versions of plugins in different 
> modules makes sense as we have different release cycles (well at least 
> that's the plan). So the only working solution right now seems to be to 
> build module by module separately.

I was about to suggest using the parent pom to specify the plugin 
version, but I see this is already done... although the 
maven-bundle-plugin is commented out right now.

Any idea why?

Herko

Re: Multi-project build is unusable

[Carsten Ziegeler <cz...@apache.org>]

Stuart McCulloch wrote
>
> yes, although releasing 1.1.0 might help with this, as we won't depend on
> plugin snapshots
> 
Yes, releasing 1.1.0 will definitly help - but we will run into the same 
problem when we start using 1.1.0 and a newer snapshot :(

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Multi-project build is unusable

[Stuart McCulloch <st...@jayway.net>]

On 07/01/2008, Carsten Ziegeler <cz...@apache.org> wrote:
>
> Hi,
>
> I just discovered that our multi-project build is unusable. The problem
> seems to be that we use different versions of the same plugin throughout
> our code base. When doing a multi project build (like using the
> build.xml), only one version of the plugin is used for the whole build -
> resulting in corrupt artifacts in the end.
> The main problem atm is the maven-bundle-plugin; some modules use 1.0.0
> while others require 1.1.0-SNAPSHOT; it seems that at least on my
> machine 1.0.0 is used everywhere.


yes, this seems to be a Maven limitation* wrt. multi-project builds, and if
one project pulls in
the 1.0.0 version then you could end up with bogus files in bundles (see the
archived thread
at http://www.mail-archive.com/dev@felix.apache.org/msg02598.html for
background)

  (* although this may just be a limitation wrt. mixing snapshot and
released versions)

last time I checked the 1.1.0-SNAPSHOT was used throughout trunk (see commit
r605980)
but the 1.0.0 version might well have snuck back in... once the bundleplugin
is released we
could use 1.1.0 throughout, and centralize the version as a property in the
parent pom
**

I think that this is a known problem of m2 - and I don't see a good
> solution for this. Using different versions of plugins in different
> modules makes sense as we have different release cycles (well at least
> that's the plan). So the only working solution right now seems to be to
> build module by module separately.


yes, although releasing 1.1.0 might help with this, as we won't depend on
plugin snapshots

Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>

-- 
Cheers, Stuart