maven-release Plugin and GitHub Issues

Posted by & filed under , .

maventxt_logo_200This one is another good find from the maven “gotchas” archives. Good enough at least to make it onto my blog 🙂

I brief, I’ve been pulling my hair for the best part of yesterday trying to figure out what’s going wrong with my maven-based project, which used to work otherwise fine until recently. It used to compile without problems, package and deploy like a dream. And then yesterday, as I found out, the release process sort of worked … but not quite the way it used to do! More to the point, it did the packaging, did the revision increment and github tagging — but it only deployed the SNAPSHOT version!

OK, there was a slight issue which I have found to be due to this aws-maven issue I’ve described previously — but that was only at the point where the packaged tarball had to be shipped to Amazon S3. The main issue though was no longer with copying files to S3 storage, but with the way the version was rev’d up.

Typically, when running a mvn release:prepare, as per http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html, what happens is that your pom.xml gets updated and the version gets changed from a SNAPSHOT version to the next release version (e.g. 2.3.1-SNAPSHOT becomes 2.3.1); the updated pom.xml gets committed into source control (SCM) and a tag gets created into SCM for the release. In the next step, when you run mvn release:perform, maven runs a full build then a deploy, and finally increments the pom.xml version to the next SNAPSHOT version (so 2.3.1 becomes 2.3.2-SNAPSHOT).

Weirdly, this wasn’t what was happening for me! Instead, on mvn release:prepare, my project was being updated from 2.3.1-SNAPSHOT to 2.3.2-SNAPSHOT! However, github was still tagged at the end of mvn release:prepare with the release version (2.3.2)! Then when running a mvn release:perform, because at this stage maven found the pom.xml version to be a snapshot one (2.3.2-SNAPSHOT) — it will run a deploy, but because the version is a snapshot one, it will deploy it to the <snapshotRepository> server defined in pom.xml.

Running the whole mvn release:prepare; mvn release:perform saw my project going from SNAPSHOT to SNAPSHOT, each time a tag for the release would be created, but no release tarball deployed, instead my snapshot S3 bucket got filled up at each step with a new SNAPSHOT release.

I’ve looked around the net but since it’s not something you can search for in a few terms, or perhaps because this issue is not so common, I got nada, zilch, nothing! So I set off to identify the issue on my own. I’ve started with a fresh standalone project, which didn’t use maven-archiver (the initial project relied on maven-archiver plugin for packaging), didn’t have sub-modules and nothing fancy. Just a simple jar project with a few classes (no tests either!), aws-maven used for deployment and the maven-release-plugin. At the time, I was using maven-release-plugin version 2.4.1 so I used the same version of the plugin in this simple project. I’ve put the project in github, just as with the other project.

The result, when running mvn release:prepare was again, that from 1.0.0-SNAPSHOT, my project will go at this step to 1.0.1-SNAPSHOT (rather than 1.0.0)! I went and cleaned up the tags, the compilation and pom.xml manually and reverted everything back. Then tried version 2.4.2 of maven-release-plugin — same thing!

It is only when I switched to version 2.5 of maven-release-plugin that everything worked as it should.

To test this, I’ve updated the original project, which used as I said maven-archiver for packaging, as well as had modules and a whole bunch of other stuff — and, hooray! it worked!

I suspect that what happened, bearing in mind that the maven-release plugin relies on the git libraries when doing the tagging and the detection of next version for the pom.xml, is that at some point my git libraries got upgraded when I upgraded/updated my Homebrew installation (I don’t do that regularly to be honest, only now and then, so now idea when the last update was done, probably a few good weeks ago). This must have caused some conflict with the maven-release-plugin for the version I had — and I suspect this is an issue that was detected a while back by the maven guys, since it seems to be fixed in version 2.5 of the plugin. However, I didn’t notice it until the recent Homebrew update when it became apparent.

Luckily, as I said, maven-release-plugin version 2.5 fixes that — so if at any point you encounter this oddity with 2.4.x versions of this plugin, try updating it to 2.5: it worked right away in my case!

Leave a Reply

Your email address will not be published.