Mike MacDonagh's Blog

Somewhere in the overlap between software development, process improvement and psychology

How to do maven releases with Jazz SCM

I’ve previously blogged on structuring maven multi-module projects to work well with m2, eclipse and Jazz SCM. In this post I’m going to write about how to do releases because it’s not as straight forward as you might hope and expect. This blog is explicitly about using maven 2.2 and IBM Rational Team Concert although it will apply to various other previous versions. Later versions of RTC should (I hope) alleviate some of the problems and the Jazz SCM Maaven plugin is being actively work on.


During development or maven projects we start with a label such as 1.0.0-SNAPSHOT which reflects the current development build. Over time the development snapshot might be occasionally pushed to a maven repository as a “snapshot release”  if it’s roughly stable so that dependant teams can get the dev version if they really want it. In time development gets stable enough to release the definitive 1.0.0 so the -SNAPSHOT is stripped from the label and the version is pushed to the repository as a proper “release” for other teams to depend on. At this point a new number is selected and development continues on the new label such as 1.0.1-SNAPSHOT which might be occasionally pushed etc.

Diagram showing how releases and version numbers work with maven

The problem

This process works pretty smoothly in a lot of contexts as the release is done by issuing a command line as simple as mvn release and maven’s smart enough to work out the rest. The problem comes in the context of Jazz SCM for a couple of reasons:

  1. The Jazz Maven SCM plugin is still in early development so doesn’t do everything well and some things not at all
  2. The Jazz Maven SCM plugin incompatible with the maven release plugin because it requires the pom scm tags to be written in a way that the release plugin can’t read
  3. The jazz scm plugin insists on outputting your password in cleartext all over the logs so you can’t do it as part of an RTC build without exposing the build user password (which depending on your organisation might not matter or could be a huge deal)
  4. Both maven and rtc use the word snapshot for different purposes and other terms like “baseline” and “tag” are synonymous

The solution

Write a little script to work around the problems with the following requirements:

  • All published version numbers in the maven repository must be reflected by RTC scm snapshots
  • The process of releasing is simple to use

To make this work I’m actually dumping the use of the Jazz Maven SCM plugin as it’s not yet developed enough to be useful. Instead since every build happens in RTC occurs in a snapshot here’s the process:

  1. Green Build in RTC (optionally promoted to RTC Release) with a known snapshot name e.g. v1.0.1 release
  2. Integrator/Releaser/Committer/Nominated dev runs custom mvn-release script on their local machine
  3. Sits back and watches, feels good

Here’s the pseudo-code for how to do it all. One of my clients is developing this currently and I’m reasonably optimistic that they might open source (or allow me to) the full script. However if you’ve got a bash monkey working for you it shouldn’t be hard to develop this up pretty quickly.

Currently this process needs some parameters which could be passed in or the user could be prompted. I prefer to pass in and prompt so that the script can be invoked from a remote process (like a build server) passing in properties or can be interactive if a user invokes it. Parameters required at least somewhere along the way are:

  • rtc user name and password
  • is this a snapshot release or proper release
  • rtc build snapshot
  • new version number to base label (if doing a proper release)

CURRENT_VERSION = getCurrentVersion(pom.xml) //1.0.0-SNAPSHOT

//If just doing a basic snapshot release
scm create snapshot "CURRENT_VERSION"
scm checkin & deliver
mvn deploy

//If doing a full release
PROJECT_NAME = getCurrentProjectName() //basename of current directory
NEW_WKS_NAME = create new rtc workspace in /tmp/rtc/workspace/RTC_SNAPSHOT_NAME/
load temp workspace with contents of RTC_SNAPSHOT_NAME
cd /tmp/rtc/workspace/RTC_SNAPSHOT_NAME/PROJECT_NAME
//Generate Release
mvn versions:set -DnewVersion="RELEASE_VERSION"
scm create snapshot "RELEASE_VERSION Release"
scm checkin and deliver
mvn deploy

//Generate new development starting point
NEW_VERSION = AskUser(); //1.0.1-SNAPSHOT
mvn versions:set -DnewVersion="NEW_VERSION"
scm create snapshot "NEW_VERSION Initial baseline"
scm checkin and deliver
//don't do a mvn deploy as that would be the user choosing to run this script choosing the snapshot-release option

//Tidy up
scm delete workspace NEW_WKS_NAME

The advantage of running this script creating a temporary local workspace and running from there is that you can do this from the command line without closing eclipse (or invoke from Eclipse as an external tool configuration). Also it isolates the release process from any possible local changes in the /Releaser/Committer/Nominated dev’s workspace.

Until the Maven SCM plugin comes of age I hope this helps.


12 responses to “How to do maven releases with Jazz SCM

  1. Pingback: Working with Maven multi-module projects in RTC Jazz SCM with m2 « Mike MacDonagh's Blog

  2. Jirong Hu May 31, 2012 at 5:10 pm

    Hi Mike

    I am at the point need to figure out how to do a release build in Maven 3 with RTC 3.0. I’ve set up a continuously build which uses JBE to call Maven’s “mvn deploy” which will do an incremental build and push the result (your “snapshots release”) to Nexus.

    After I read a lot in the forum regarding “meven-replease-plugin” and “Maven SCM Plugin for RTC”, I think your approach is a better workaround for now. A couple of questions:

    1. Can you email me a copy of your sample script? Or is it published to open source yet?
    2. I want to embed the RTC snapshot/baseline into each build result, how it is handled in your approach? You mentioned in the requirement but I don’t see that in the solution.
    3. I want to do this “proper release” automatically every night, let’s say we call it a release build which takes the latest successful continuously build baseline and do a clean full build and publish the results to Nexus (“mvn clean deploy”). How to achieve this?


  3. mikemacd May 31, 2012 at 9:43 pm

    Hi Jirong,

    1. Unfortunately not, I’ve not been able to open source it from my client for a couple of reasons 😦 Sorry about that.

    2. The RTC snapshots are linked to the maven releases simply by the convention of using the maven version identifiers in the names of the RTC snapshots. Additionally you can call out to the ant build toolkit tasks to add external links to your build record which can point to the artifact in Nexus. Does that answer your question?

    3. That’s fine, you just need a way of making the script non-interactive by either defaulting the parameters or reading them from a build.properties file (which you can then override from the build request if you want).

    I know a lot of work is going into the official plugin at the moment so it’s worth keeping an eye on that too.


    • Jirong Hu May 31, 2012 at 10:10 pm

      2 is not clear. It’s the other way around. Before release, Maven’s snapshots version is fixed, e.g. 1.0.0-SNAPSHOT, but each time we run a Maven snapshot build, the baseline/snapshot from RTC is different. The problem I want to resolve it to embed the RTC source code baseline/snapshot in each of new 1.0.0-SNAPSHOT Maven is produced.

      • mikemacd June 4, 2012 at 3:37 pm

        I think I know what you mean, the problem is that maven repeatedly uses 1.0.0-SNAPSHOT whereas in RTC we’d have several build records as time goes by so how can you explicitly associate the RTC build with the maven version currently deployed? I’ve not found a good answer for that myself 😦

        • Rob October 24, 2012 at 2:50 pm

          Not sure if this helps answer the question, but using the jar / war plugin in maven, you can specify the implementation version in the manifest of the built component. I’ve defined this in my pom to be something like the below. This might not be what you want, but essentially the implementation version of the component now becomes a combination of the maven project version and RTC build label. In my build definition properties I simply set build.label=${buildLabel}. As you know, the implementation version is accessible through code.
          I can also override the build.label property in a DEV environment where RTC is not running the build so it has some DEV setting (e.g. ROB-DEV), so I can immediately see where the jar / war was built from (if set).

          [MMD Edit: code moved to next comment]

          • Rob October 24, 2012 at 3:02 pm

            Sorry – tags removed in previous post…hope this works…

  4. schandra March 14, 2014 at 8:05 pm

    I am using maven in command line and i am trying to publish/ deploy my binaries to RTC as admin user. however i keep getting access denied errors bcoz the default password which i defined in settings.xml for ADMIN user (blank password) is not being recognized. any ideas or suggestions are greatly appreciated.

    • mikemacd March 17, 2014 at 5:45 pm

      Sorry schandra, it’s bound to be something environmental, not something I can help with without knowing the details.

      • Har sree April 7, 2014 at 7:00 pm

        Hello Mike ,
        Thanks for the response and yes, it was environmental issue. I was able to successfully publish to RTC using maven. I have a question on SNAPSHOT versions though. I have a maven-multi-module project and here is my project structure

        Parentproject (parent for all the modules)
        –ears (parent for ear)
        – ear1
        –jars (parent for jars)
        -jar 1
        -jar 2
        –ejbs (parent for ejbs)
        – ejb1
        –wars (parent for wab modules)
        the version number(1.0-SNAPSHOT) is specified in the parent modules and the child modules inherit version from there ${project.version}. I was able to build the modules and publish the artifacts to RTC. When i try to consume this SNAPSHOT dependency in one of my other project I am not able to ..its giving me an “artifact descriptor not found ” error.. however if i use “1.0” as my version for these artifacts and try to consume say for ex: jar 2 then it pulls in all the artifacts of Jar2 + pom.xml of the jars ,its parent + pom.xml of parentproject , its parent.

        so the question is have you tried pulling down the SNAPSHOT artifact dependencies using a maven build? If yes, can you please shed some light on how you did that.
        NOTE: we are not using Jazz SCM plugin or any other plugins, Just using simple mvn clean -U install deploy command
        Thanks in advance.

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: