Having 'mvn deploy' in Hudson's build goals and the standard approach of releasing

Question

I set up Hudson for my project with the build goals mvn clean deploy site:site, run a build every midnight and whenever there are new changes.

One thing I have been wondering is whether I should include deploy in the build goals because it could happen that if I had just released version 1.0.0 of my project (I've changed the pom to be version 1.0.0 and committed it) but not yet increased the version number to 1.0.1-SNAPSHOT for several days, I could end up with multiple different 1.0.0 builds being deployed at different times.

But I've seen people are using deploy in their Hudson's build goals - I wonder how they deal with this issue.

What's the correct way of doing a release with Maven actually? Thanks for any pointers!

Answer 1

You should continue to do automated nightly deploy(s) from Hudson, but the larger issue regarding how to handle version numbers and releases is intricately tied up with whatever your source code control system is. You didn't mentioned what kind of source code control system you are using, but I can explain how to do this using Subversion.

Firstly, for the reason you mentioned, you should never change the version identifier of your source code in trunk to anything other than a snapshot version (e.g. with a -SNAPSHOT on the end). Otherwise you will overwrite when you re-deploy. The best practice is to (temporarily) change the version identifiers in your trunk pom(s) to the version you want to release, tag the trunk, build from the tag, then deploy the build you made from the tag, then immediately bump up the snapshot version identifier in trunk, and finally commit the trunk with the newer, higher snapshot version number.

If this seems like a hassle, then you should know that the Maven Release Plugin will do all this for you automatically by relying on the Maven SCM Plugin to do the work with your source control system.

While I have grown to love invoking the Maven Release Plugin from Hudson, it is a very touchy thing. In order for it function properly here are a few tips:

• Real releases need to be executed by Hudson, but developers can certainly also do them from their development machines to test out the release process. Just be sure to delete any tags in Subversion and any release artifacts in Nexus afterwards.
• It uses the maven-scm-plugin which in turn requires an externally installed version of subversion to be on the current path. Thus version of subversion must also have already cached the credentials necessary to write into the subversion source repository.
• If a release process aborts itself part way through you can do a release:rollback to fix the poms, but this won't eliminate any bogus tags that have already been committed to subversion. These you'll have to delete manually, after doing an svn update.
• The release:rollback goal sometimes doesn't return the pom.xml version back to a SNAPSHOT. If anything goes wrong, check the POM version to ensure "SNAPSHOT" is used.
• The release:rollback goal sometimes doesn't return the SCM URLs back to their original location. If anything goes wrong, check that these point to "trunk" or the originating branch.
• Because we use Subversion our configuration of the maven-release-plugin enables the {{suppressCommitBeforeTag}} option which eliminates an extra commit that would other modify the trunk pom.xml files before modifying them back.

Also note that there is a Maven Release Plugin integration with Hudson, but it is not required to invoke the Maven release plugin goals from Hudson, it just makes it easier, however, I have had no luck getting that plugin to work.

So to summarize:

1. Only deploy from trunk using SNAPSHOTS
2. Use the Maven release plugin to deploy from a tag during a release.

Hope this helps.