Maven Release Plugin war stories

Question

Hello,

I have been given the task of exploring the maven-release-plugin before we try using it on our project. As of now, the releases are done manually on request. This process involves (skip this part if you're not interested, it's just to give you an idea):

• In the head, open the base POM file:
  • Increment the numbering of the \project\version element, but keep the -SNAPSHOT suffix.
  • In the \project\dependencyManagement element, look for all the project dependencies that are being released in this build, and increment the version number references \project\dependencyManagement\dependencies\dependency\version, but keep the -SNAPSHOT suffix.
• Open each sub-module's POM file in turn and increment the numbering of the \project\version element, but keep the -SNAPSHOT suffix.
• In a command prompt, navigate to the root of the head codebase and run mvn clean install.
• Ensure that all the version dependencies work correctly, and the full test suite runs successfully.
• Commit changes to the head.

As you can see, this is a lengthy and dull process which cries out for automation. I have found this question on SO where people recommend doing releases manually, which is kind of against what I am trying to achieve.

Automate this

We would like to automate this process using the maven-release-plugin but we are a bit wary of doing this. My research has led me to believing that the plugin should work reliably and do the job.

I have seen the -DdryRun=true option for the release:prepare target which also makes the impression that it can be tested safely beforehand. Also the Maven release:rollback target seems to provide a reasonable means of reconciling from an error. But I am still not sure. Not as sure as I would like to be about this plugin.

My question is, do you have any war stories related to the maven-release-plugin? Any good/bad experience with it? Is the plugin robust enough to trust it?

<<<EDIT

I also heard that the plugin integrates well with the SCM tools such as SVN, CVS. We are currently using CVS, and would like the plugin to perform the following tasks as well:

• tag the release in CVS with the appropriate release number
• create branches in CVS with appropriate names
• should allow us to do a release from a branch with minimal config hassle

Have you got experience with this? Does it work well? Is it reliable?

>>>

Answer 1

I am using maven release, but I did not try the rollback. I am for automatic release process, it saves a lot of time. In the manual approach you can do something wrong each time you release something so it has a higher risk.

My suggestion is to give it a try to see if covers your needs, it should not be a big effort to use it in a maven project.

Answer 2

We're using the release plugin and it works great for us. It makes releases much faster. release:rollback works too, but I don't think it deletes the tag from subversion if it was already created.

We've been doing that manually, but 99% of the time we don't have to rollback.

Answer 3

My recommendation- try the plugin, if it works for you as-is, great, you're done. Otherwise sketch out what you need to accomplish and write it simply in Ant (which you can call from Maven). You'll spend far more time trying to make it work through various hacks in the pom than you will writing it in Ant. I've long since given up trying to fight various maven plugins that don't work out of the box.

Answer 4

We use the maven-release-plugin all the time. It works really well. We almost never have to touch the project/version element in our pom files since the plugin updates that for us. As I'm sure you've read in the documentation, the plugin does the following:

release:prepare

1. Compiles your project to make sure all is in order
2. Updates the project/version in the pom file to remove the -SNAPSHOT
3. Creates a tag based on your current project
4. Updates the project/version in the pom file to the next version, which you provide when running the plugin
5. Check in the updated pom file

release:perform

1. Checks out the tag created by the release:prepare into the target directory
2. Execute a 'mvn deploy' on the checked out project. This also passes the flags that deploys a source and javadoc package as well.

The only time we have to touch the project/version of the pom is when we want to rev a digit other than the last. Otherwise, the defaults are typically all that is necessary.

I haven't tried the release:rollback goal, but rolling back a release is pretty simple to do manually. Steps include:

1. Delete the tag from your SCM system
2. Edit the pom.xml to reset the project/version to the SNAPSHOT version that was just released.

This process works fine whether building from the trunk or from a branch.

Answer 5

The maven release plugin works excellently for me, though I do have one caveat. Make sure that you're using 2.0-beta-9 or later if you are using subversion. Earlier versions blow up whilst tagging.

Answer 6

We use the release plugin for all maven based releases in the Apache Maven project, as well as at Sonatype. It does a good job of managing the version changes within a given build, even if they are defined as properties.

As I mentioned in the other thread, it doesn't manage versions external to the build being released. I prefer to do this by hand, but there is also the versions-maven-plugin that can assist with this.

A properly structured build will move out the things that don't change very often or are shared with other builds to a separate release cycle. Because of this, it is rare to find a build that is completely self contained such that it's possible to fully automate the entire release of many disconnected modules. I gave an overview of how I manage my builds on the above referenced thread, but note that I'm not changing every version by hand, just the ones that are external to my build. I want control over those and not just to grab the latest simply because it's available...it's about managing risk between releases.

All that being said, I have been in situations on previous projects where the release plugin wasn't feasible even if it technically did work. This had more to do with the length of time our builds took and network factors more than the plugin itself. However, in those instances we managed to bump the versions with a script and follow the same generic process that the release plugin does:

1. Build and Test

2. Bump the versions to releases.

3. Commit.

4. Tag.

5. Bump the versions to the next snapshot.

6. Commit.

7. Checkout the tag, build and deploy.

There are several enforcer rules I developed during this time of running a release by hand to help detect any issues related to it, specifically to validate I had no snapshot dependencies left, that none of the artifacts themselves are snapshots, etc. You can see those here.

Answer 7

I haven't used it with CVS, only SVN, so my response is based on my own experiences. I think the plugin (2.0-beta-9) is robust enough to trust it, but like other maven lifecycle approaches, using the release plugin comes with a number of implied commitments.

You may run into some issues surrounding classifiers. Be sure to check all of the open tickets to know what to watch for.

Before you use the release plugin, realize that it means you will (for a few seconds) have non-snapshot POM versions checked into your development mainline, instead of safely stashed somewhere else. If a developer updates during those seconds, they will get seriously confused when they start coding. Personally this bugs the heck out of me, but I'm resigned to it; creating a workaround is not worth it right now.

Releasing from a branch should be no problem, and the plugin will create tags for you as part of the release:prepare step. Depending on your branching strategy, this may make the issue above irrelevant.

I strongly recommend that you have each multi-module project keep all siblings released on the same schedule. If you combine this with dependencyManagement in the right places, it will leverage the release plugin to best effect.

My biggest control battle with Maven (in general) is that the artifact version identifiers are committed right into the version control system in the POM, instead of being defined using metadata (e.g. branch names or tag names) from the VCS (which is how I always preferred to do it, but Maven is contrary). If you want your developers' tools to "just work" with maven as expected, I haven't found a good workaround for this. This issue reaches its pinnacle with the release plugin: for example, it changes the POM to look the way it should look on a branch, commits that, and then creates the branch! But if you can accept this (and if you plan to keep using Maven, you will probably be happier if you do), then the release plugin fits fairly cleanly into the process.

Answer 8

Agree with the previous comments, it works most of the time.

One thing to keep in mind is that it does NOT currently update parent versions that are SNAPSHOTs to the release version. See MRELEASE-449

Answer 9

I've been trying to evaluate the maven-release-plugin too, but i'm constantly hit by bugs (some open for more than 3 years !)

As you also use CVS, here are some of the things:

• http://jira.codehaus.org/browse/MRELEASE-128 -> you can't use variables (like cvs-user) in your SCM URL
• http://jira.codehaus.org/browse/MRELEASE-261 -> flat hierachy is only supported with SVN in recent versions