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.