maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maczka Michal <>
Subject RE: dependencies in reactorized builds
Date Tue, 01 Feb 2005 09:42:30 GMT

> -----Original Message-----
> From: Vincent Massol []
> Sent: Tuesday, February 01, 2005 10:00 AM
> To: 'Maven 2 Developers List'
> Subject: RE: dependencies in reactorized builds
> Hi Michal,
> We have a big project at work (some 100+ projects with 60+ 
> developers as of
> now). This is all a single application that goes in the same 
> EAR (we could
> have some smaller EARs but that wouldn't change the pb).
> We need to ensure all those projects share the same version 
> of dependency
> libraries they use (log4j, hibernate, commons-*, etc). ATM we're using
> entity include but that's not a very nice solution.
> I don't see what's the relationship with releasing all at 
> once. We simply
> want to be sure all the projects are using the same external library
> versions.

Salut Vincent

The problem is that we talked about containng the information about
"prefered versions" in poms

To understand that problem take a look at:
POM which is shared by all plexus components in plexus cvs repository:

This pom already has version 1.0. It means that it was suposed to be
released/deployed to some remote repository

as plexus/pom/plexus-components-1.0.pom

This pom defines common set of dependencies shared by all plexus components
which are:


You could have more of them here (e.g. common version of log4j etc)

All component project are referencing this common pool of dependencies using
project inheritence:


Now the problem is that if I want to upgrade the version of
plexus-container-default which is used by all components
I have to modify the parent POM of plexus-components and deploy it to the
repository (e.g. as plexus/pom/plexus-components-1.0.1.pom) 
This change won't be directly visible to component projects as they are
still using version 1.0.

So the idea which we are trying to investigate here is how to fix this
problem. The solution which was proposed
was to share the same version across the board - so you don't have to change

As you can see plexus-components POM has itself its parent:


So in the worst case if I change something in the pleuxs "ROOT POM" 
to propagte this change I will have to modify all other poms in plexus cvs
repo - which means I have couple dozens of poms to modify!!

In m1 this was easly doable as parent pom was not versioned and relative
path to it was hardcoded in child poms.
For m2 things are looking diferently as you have to explicitly define the
version of the parent project. 

So what Jasons described here

"The group POM, for lack of a better term. Would be the POM that sits at
the top-level and would really be the place where this information would
be contained. Say the group POM for geronimo, or the group POM for
plexus. I honestly don't think we will need two types of POMs because
the POM for the group will really only contain overall group information
and defaults."

is still affected by this problem. 

At the momment I cannot think of other solution then to have some poms
unversioned or referened by some sort of pointers (like we do with SNAPSHOT



View raw message