Maven Release: Prepare/Perform after Rollback incorrectly succeeds with wrong content

Question

We use Maven with Subversion internally. We also use Maven's Release plugin. We noticed the issue described below when running through the following (correct, I presume) steps.

1. We run release:prepare:

• Maven updates the trunk version to 1.0.0.
• Maven runs svn copy trunk/myproject tags/myproject-1.0.0, thus creating tag myproject-1.0.0.
• Maven updates the trunk version to 1.0.1-SNAPSHOT.

---

2. We run release:rollback:

• Maven resets the trunk version to 1.0.0-SNAPSHOT.
• Maven does not remove the tag, because Maven doesn't do this kind of stuff.

---

3. We commit more changes to trunk, obviously against version 1.0.0-SNAPSHOT.

---

4. We run release:prepare again:

• Maven updates the trunk version to 1.0.0.
• Maven runs svn copy trunk/myproject tags/myproject-1.0.0, thinking it created tag myproject-1.0.0 out of the latest trunk. But, alas, Subversion (1.6 and 1.7 alike) will instead create tags/myproject-1.0.0/myproject on Maven's behalf.

---

5. We run release:perform:

• Maven checks out the contents of tag myproject-1.0.0.
• Maven builds the contents and deploys the result to Nexus.

The problem is obvious: the change in step 3 did not make it into the tag. We are now releasing 1.0.0 without the change in it.

The questions are: How can we fix this? Is Maven's release rollback feature inherently broken?

Answer 1

In fairness, rollback should reset the project and SCM to a state that allows a second prepare to occur. This includes removing the tag. The answer is now apparent (Googling "maven release rollback remove tag"):

http://maven.apache.org/maven-release/maven-release-plugin/examples/rollback-release.html:

The created branch/tag in SCM for the release is removed. Note: This is not yet implemented so you will need to manually remove the branch/tag from your SCM. For more info see MRELEASE-229.

The resolution would then be to force release:rollback to include a command to delete the SCM tag using something like org.codehaus.mojo:exec-maven-plugin. Short of this, wrap rollback inside a script that does that externally.

Answer 2

As you've discovered, release:rollback doesn't have a whole lot of utility when it doesn't clean up SCM. What our shop has done is setup our Jenkins automation to run "mvn release:prepare release:perform" in combination with the Jenkins M2 Release Plugin.

If it fails we need to delete the tag in Subversion but, then again, we would have to do this anyway with rollback.