I am working with Maven for the last 2 months. I think I understand it just enough but not yet sure :) I got the Snapshot build compiled, installed and deployed to our team repository.
So the plan is the use Snapshot builds for Dev environments and Once stable tell the QA team to use that for QA and once QA accepts the build, promote the same build to production.
My requirement if a snapshot build is found to be good. I want the exact bits on production.
If I use the release plugin the issue it tags and rebuilds the sources and checks out the tag and deploys it (Removing SNAPSHOT from version string in the process). The problem here is that I cannot guarantee that it has the same bits as the Snapshot build that QA accepted.
Also, I feel it is redundant to tag the build because Jar manifest has the SVN revision. So I can always go back to that SVN revision to retrace the build from a Maven artifact Jar.
So my question, Is there a easy way to promote a snapshot build which is found to be acceptable to QA team as is ?
You can't have 'the same bits' if you use snapshots. You can have bits built from exactly the same source. Use the build-number-plugin to capture the source control revision into the build. WHen QA likes it, tag that rev and make a branch. Then manually set the version number to the desired release version.
Or, stop hitting yourself in the foot with a brick and use the release plugin as intended.
You need to use release staging. Run the release plugin to produce a real release, with a tag, but with the artifacts jailed in a staging area (via Nexus Pro, the next release of Archiva, or the use of altDeploymentUrl). Have QA test the staging area version. if they bless it, promote those bits to the formal release area. If QA dings it, delete the tag and delete the staging area.
Thus you accomplish testing the very bits that you imagine shipping.
I'm researching this issue too. I'm a hard-core Maven user, and I still bang my head against the wall with the release plugin (especially when used with Mercurial).
Here are some additional, relevant links I've run into:
That last one still relies on
maven-release-plugin, but at least it goes into more depth on the pitfalls of using it.
We're thinking of moving to a simpler approach using our own scripts to manage the process, using Maven to update the version numbers (e.g.
mvn versions:set -DnewVersion=1.1.0) but implement our own branching/tagging/committing workflow.
One approach is to let the CI server together with your binary repository. The you can skip the
Here is an example of how it is being performed using TeamCity Artifactory Plugin - Release Management.
I am sure that the same possibilites are there if you use another CI server like Jenkins and also together with another binary repository like Nexus.
There's a brilliant blog here describing a fairly simple alternative to using the maven release plugin. We will be using an adaptation of this strategy on our project, it avoids many of the problems and complexity of the release plugin.
Maven Releases on Steroids