Maven internal library pom version management - maven

Question

Are there any tools and/or best practices to help with managing a large set of internal libraries versions across many dependent projects. Allow me to elabore,
Say you have products A, B, C.
These products depend on libraries X, Y, Z, and there are dependencies within those as well.
In this world, we like to keep all versions on the latest released version of all dependencies (no snapshot dependencies except in working copies). This allows us to release the product at any time and force all projects to be run in CI (Hudson).
The issue is in keeping the pom.xml's all up-to-date. Currently, we use a custom maven plugin that, as part of each release, searches our SCM for pom.xml's that depend on the project being released and updates it. This is similar to the versions-maven-plugin except that you don't need a working copy of each project to do it.
There has got to be a better way. What do other teams do about many shared libraries across many projects? What is the best way to organize this? Multi-module works in some cases, but most of our libraries are fairly independent and used by too many other projects to (a) decide which multi-module it would belog to and (b) the hierarchy that would work for this.

Answer 1

managing dependencies in Maven works fine with dependencyManagement - I think you are familiar with it. You can outsource this dependencyManagement to a dedicated POM: a so called BOM POM (see http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html).
In your case this BOM POM might be shared by your products A, B and C. Due to that fact you should define a Maven project just containing this BOM POM with all the dependency management for thirdparty software X, Y and Z. This project can be released and you are able to add a dependency on your BOM POM with the scope import.
Your BOM POM:
<project>
<groupId>com.acme</groupId>
<artifactId>my-thirdparty-bom-pom</artifactId>
<version>1.0-SNAPSHOT</version>
...
<dependencyManagement>
<dependencies>
<dependency>
<groupId>...</groupId>
<artifactId>X</artifactId>
<version>...</version>
</dependency>
<dependency>
<groupId>...</groupId>
<artifactId>Y</artifactId>
<version>...</version>
</dependency>
<dependency>
<groupId>...</groupId>
<artifactId>Z</artifactId>
<version>...</version>
</dependency>
</dependencies>
<dependencyManagement>
...
</project>
Sample import for project A
<project>
...
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.acme</groupId>
<artifactId>my-thirdparty-bom-pom</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>import</scope>
<dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>...</groupId>
<artifactId>Y</artifactId>
<!-- the version is managed by the thirdparty bom imported above -->
</dependency>
</dependencies>
...
</project>

Answer 2

The closest thing is to use Dependency Version Ranges and then in a profile override your pom's repositories changing snapshots to false, making sure to include your profile during release with "-P".
<dependency>
<groupId>a</groupId>
<artifactId>a</artifactId>
<version>[3.8,4.0)</version>
</dependency>
...
<profiles>
<profile>
<id>your-release</id>
<repositories>
<repository>
...
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
</profile>
<profiles>
Another pattern is the "bom" whereby you create a pom (packaging: pom) that declares a list of dependencies to make management easier (less to change).