Releasing with Maven

I recently released a maven project and could not stop thinking that the whole process is very complicated and error prone. Let us say I have an application which consists of 3 modules A, B and C, each having its own folder in subversion and a separate build job in Hudson. Each module has a parent POM which aggregates multiple artifacts. A depends on B, and B depends on C. The dependency versions are defined in a top level POM D, which is the parent of A, B and C. It does nothing else than making sure all versions are kept in one place and that there is only one version of each artifact used in the whole project. In order to make the release I do the following:

1. Release the top level POM D with the release plugin through Hudson.
2. Start at C which has no further dependencies.
3. Change C to reference the released version of D. Release C with the release plugin.
4. Enter the released version of C in D, so modules that depend on C can be released with the stable v开发者_JAVA技巧ersion of C.
5. Release D again with the release plugin.
6. Do 3-5 for B
7. Do 3-5 for A

After that I have stable non-snapshot builds of all artifacts in A, B and C and can assemble them together to a final stable release of the application.

In real, I had not only 3 but like 20 such modules. Now I find this procedure very complicated and I think it has a lot of potential problems:

• I need to release D several times, once for each level in the dependency hierarchy. In the end I have D with only stable versions of A, B and C in it. To go on with the next development version I have to edit D again and reference all the new snapshot versions of the released modules. In general, the dependency management has to be done all by hand, even when using the release plugin.

• If somebody commits while I am doing the release it could mess up things. To be sure I would have to checkout a specific revision over all modules, build and test it, and then do the release for all modules on that revision. But how do I ensure that with Hudson and multiple jobs?

• Dependent on 3 different systems: Subversion server, Hudson server and the Maven archive server. If only one is down I can not release anymore.

• Time consuming. In this process a lot of building, packaging, uploading, downloading, extracting, etc. is made again and again for each module I release. A lot of redundant data exchange with the archive happens. But actually everything could be done locally, since Hudson has all the source code it needs. Just once in the end the final package needs to be uploaded.

• Say I loose the packages on the archive server. There is no easy way to tell Hudson to check out the tagged versions and rebuild them all in the proper order.

Why can this not be as easy as checkout all the code in one shot, adapt one global version, build and test it, commit, tag the commit and finally upload the binaries?

Thanks for any ideas on this.

It can be that easy. Using a parent pom, you can have all your modules point to the same parent. Then set the child modules version to: ${version.properties}, when you run a build run it with mvn -Dversion.properties x.y.x-SNAPSHOT (for dev) or x.y.z for a production build, then all the modules will be deployed at once with the same version.

So for an automated build to to specify a <version.properties>1.1.1-SNAPSHOT</version.properties> in the settings.xml, then if you need a released product specify an additional parameter at runtime with the -Dx.y.z to override the settings.xml file.

The only trick to this is your parent pom needs to have a non-dynamically-specified version, and that will need to be set in all the child documents as well. So after each release you may want to update that version number manually (though there is probably a plugin for it)

If you are always releasing your modules in sync, I would have a single parent pom for the whole project which includes all the modules and makes sure all the version are the same. When you release the top level, it releases all the modules in order with the right versions in one go.