Fixing two problems with Maven + Mercurial + Hudson

Today I've made some improvements with my Mercurial + Maven + Hudson
setup - and reached a new level of karma, being able to do automated
releases.



Let's go in order. First let me recap what happens with the Maven
release plugin (mvn release:prepare release:perform) and Mercurial:

1. A check is performed that there are no uncommitted changes
   and a build is performed as a validity proof.
2. All the version labels in the current project are updated
   (e.g. 1.3.7-SNAPSHOT to 1.3.7) and changes are committed
3. A tag in the SCM repository is made for the new release
   (e.g. release-4.5)
4. All the version labels are updated again (e.g. 1.3.7 to
   1.3.8-SNAPSHOT) and changes are committed again
5. Another copy of Maven is spawned on a temporary directory
   where sources are checked out from the SCM, with the previously created
   tag; another build is performed and artifacts deployed.
   

It's a robust sequence, as it makes sure that there are no
inconsistencies in version sequences and the release is built exactly
from the tagged files.



But there are two specific problems with Mercurial:

1. The fact that Mercurial is a distributed SCM is not fully
   exploited. You recall that commits are only performed locally and not
   shared until a push is performed. It would be a nice thing if the push
   was performed at the very end of the sequence, so in case something
   went wrong, you can rollback everything. Unfortunately, Maven performs
   the push at the end of step #4, and something can still fail during
   step #5. I suppose that since step #1 performs a full build, Maven
   developers thought that we have a proof of the validity of the build,
   but unfortunately in the real world everything can fail at every time
   (for instance, an OutOfMemoryError).
2. The check out performed at step #5 is indeed a Mercurial
   clone, that is executed from
   the
   remote repository. This is a very stupid thing, since
   Mercurial
   repositories can be huge, so this operation can be time consuming
   and expensive; the local repository could be cloned in a more efficient
   way, but it sounds as a hard fix for Maven.

I'd say that the former is a real problem, while the latter is a
serious annoyance. Here how I fixed both problems.



First, I've used a property in the SCM section of the pom for
specifying the URL:



<scm> style="font-family: monospace;">
   
<connection>scm:hg:http://kenai.com/hg/forceten~src</connection> style="font-family: monospace;">
   
<developerConnection>scm:hg: style="font-weight: bold;">${staging.hg.repo.url}</developerConnection> style="font-family: monospace;">
   
<url>http://kenai.com/projects/forceten/sources/src/show</url> style="font-family: monospace;">
</scm> style="font-family: monospace;">


<properties> style="font-family: monospace;">
   
<staging.hg.repo.url>https://kenai.com/hg/forceten~src</staging.hg.repo.url> style="font-family: monospace;">
</properties>



In this way the URL can be overridden with a property such as  style="font-family: monospace;">-Dstaging.hg.repo.url=something:
the idea is to prepare a temporary, local repository where Maven pushes
all the changes made for the release; furthermore, the clone at step #5
is performed from that local repository, thus saving time and
bandwidth.



Second, I used the altDeploymentRepository
property of the deploy plugin (which is called by the release plugin)
that allows to override the definition of the target Maven repository
and make it point to a local folder. At the end of the process, I have
that all the
changes are stored locally; in other words, I've used style="font-style: italic;">staging repositories
both for the sources and the build artifacts. If there are no errors, I
can later push the local Mercurial repository to the public Mercurial
repository and copy the artifacts in the Maven repository to
my public Maven repository.



This is the required configuraton for the maven release plugin:



<plugin>

   
<groupId>org.apache.maven.plugins</groupId>

   
<artifactId>maven-release-plugin</artifactId>

    <configuration>

       
<arguments>-Dstaging.hg.repo.url=${staging.hg.repo.url}
-DaltDeploymentRepository=release-repo-hudson::default::${staging.mvn.repo.url}
-Dstaging.mvn.repo.url=${staging.mvn.repo.url}</arguments>

    </configuration>

</plugin>



Basically we are propagating the relevant properties to
the spawned instance of Maven; there's a little verbosity as we need
the Maven staging repository expressed in form of a URL (see below)
while altDeploymentRepository needs
it prefixed with some specific Maven repository notation.



Maven should be called with these options:



-Dstaging.hg.repo.url=/my/hg-staging-repo
-Dstaging.mvn.repo.url=file:///my/mvn-staging-repo style="font-family: monospace;">


For copying the Maven artifacts from the staging repository to a public
one the wagon-maven-plugin can be used, as it has an option to merge
two repositories (goal wagon:merge-maven-repos); the required
configuration is:



<plugin> style="font-family: monospace;">
   
<groupId>org.codehaus.mojo</groupId> style="font-family: monospace;">
   
<artifactId>wagon-maven-plugin</artifactId> style="font-family: monospace;">
   
<configuration> style="font-family: monospace;">
       
<source>${staging.mvn.repo.url}</source> style="font-family: monospace;">
       
<target>https://services.tidalwave.it/nexus/content/repositories/releases/</target> style="font-family: monospace;">
       
<targetId>maven2-release-repository.tidalwave.it</targetId> style="font-family: monospace;">
   
</configuration> style="font-family: monospace;">
</plugin>



It is possible to call it by a separate Maven invocation after the main
build, or it can be
specified in the goals of the release plugin:



<plugin>

   
<groupId>org.apache.maven.plugins</groupId>

   
<artifactId>maven-release-plugin</artifactId>

    <configuration>

       
<goals>deploy wagon:merge-maven-repos</goals>

       
<arguments>-Dstaging.hg.repo.url=${staging.hg.repo.url}
-DaltDeploymentRepository=release-repo-hudson::default::${staging.mvn.repo.url}
-Dstaging.mvn.repo.url=${staging.mvn.repo.url}</arguments>

    </configuration>

</plugin>



In this way, mvn
release:prepare release:perform does all but Mercurial
synchronization; the latter task just needs a regular hg push and can easily
be performed by a post-build script.



If I get an error, nothing gets out of my disk, so I can delete the
staging repos, fix the problem and retry.



It is also possible to skip the synchronization between the staging
repositories and the real ones, in case one only wants to test the
process. For instance, I'm trying to have the artifacts generated by
the assembly plugin deployed and I'm not able to do that yet; my trials
and errors can be done locally without polluting the public
repositories.