+1. I recently got burned by using properties as a dependency version, management section or not. This issue is described here: http://jira.codehaus.org/browse/MNG-2486
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 [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon 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: <dependencyManagement> <dependencyGroups> <dependencyGroup> <groupId>org.apache.openejb</groupId> <version>2.2-incubating-SNAPSHOT</version> <dependencies> <dependency> <artifactId>openejb-core</artifactId> </dependency> <dependency> <artifactId>openejb-builder</artifactId> </dependency> <dependency> <artifactId>openejb-pkgen-builder</artifactId> </dependency> <dependency> <artifactId>openejb-yoko</artifactId> </dependency> <dependency> <artifactId>openejb-sunorb</artifactId> </dependency> </dependencies> </dependencyGroup> </dependencyGroups> </dependencyManagement> 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. --jason --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
