We need to be careful with the versions and release procedure on Maven. I've found two issues from simple testing: 1) Dependency Synchronization We need to keep the dependencies in synch, Maven has no notion of a project being part of a build only a top level build incorporating other builds. e.g. The common project is at 2.0.1.GA (released) If you build from the top level "build" folder it works fine. It uses the "modules" defined there. If you build at the lower level, e.g. common-logging-log4j, it is broken because that has an out-of-date dependency: <dependency> <groupId>jboss</groupId> <artifactId>jboss-logging-spi</artifactId> <version>2.0.0</version> </dependency> Solution: I believe there is a report you can run that helps you "synchronize" dependencies across projects/modules. We should also use the transitive dependency mechansim of Maven2 where possible to reduce the amount of explicit dependencies we right. 2) Changing the version after a release. If you look at JBoss Common, it is released at 2.0.1.GA The pom files in trunk still say 2.0.1.GA so if I do "maven install" after doing some changes I overwrite the released jars with my own. This potentially breaks the other builds that expect 2.0.1.GA not my 2.0.2.alpha stuff. Solution: The release procedure should be something like: a) Set all the versions to the release version b) Run the report mentioned in (1) to check dependencies are consistent c) Tag and Release d) Update the versions to the next development version -- xxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxx