Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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 version 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.

like image 855
anselm Avatar asked Mar 12 '11 19:03

anselm


People also ask

What is Maven release process?

Maven will compile, test and package the versioned project source code into an artifact. The final deliverable will then be released into an appropriate maven repository. The release:perform goal will: Extract file revisions versioned under the new tag name.

What is Release Candidate in Maven?

Release Candidate (RC) is the build released internally to check if any critical problems have gone undetected into the code during the previous development period. Release candidates are NOT for production deployment, but they are for testing purposes only.

What is snapshot and release in Maven?

A Maven snapshot is a special version of a Maven package that refers to the latest production branch code. It is a development version that precedes the final release version. You can identify a snapshot version of a Maven package by the suffix SNAPSHOT that is appended to the package version.


1 Answers

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)

like image 161
Nathan Feger Avatar answered Sep 21 '22 17:09

Nathan Feger