maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian E. Fox" <>
Subject RE: Grouping dependencies to share common config
Date Wed, 04 Oct 2006 19:44:33 GMT
+1. I recently got burned by using properties as a dependency version,
management section or not. This issue is described here:

Basically the properties are not resolved before the pom is deployed so
something like project.version will stay in the exported pom and then
require snapshot versions that exactly match it's own (which isn't
possible since they are timestamped).

-----Original Message-----
From: Jason Dillon [] On Behalf Of Jason
Sent: Wednesday, October 04, 2006 3:33 PM
To: Maven Developers List
Subject: Grouping dependencies to share common config

Hi, the Geronimo project has a fairly large dependency list, may of
which are for dependencies with the same groupId and version.  I was
thinking it would be nice to have built in support to the pom to make it
easier to manage these groups, with out needing to use properties.

The problem with properties is that the definition of the property is
often far away from the dependency def, which makes it harder to look at
the pom and see what versions are really being used (as you need to
bounce back and forth from dependencies to properties).  And, when the
properties are present I find that people tend to just copy dependencies
from dependencyManagement to their child poms verbatim, which is not
ideal and complicates the management of the versions even more and
promotes the practice of making all versions properties which is not
very good IMO.

What I was thinking was something along these lines:


Dependencies within the group would pickup any missing elements from the
group.  The the above example, the groupId and version defined in
dependencyManagement/dependencyGroups/dependencyGroup would be used for
all dependency elements with in the group which omitted those elements.

I'm not sure of the exact syntax, but the basic concept would really be
helpful for projects with a large number of dependencies.


To unsubscribe, e-mail: For additional
commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message