Ted Vinke's Blog

Java, Groovy and stuff



Continuous Integration

Release Notes with Groovy and JIRA REST API

JIRA is Atlassian‘s kick-ass issue tracker and in use in many projects I’ve been in. In my current project we use JIRA’s release notes after a certain version has been released, but some departments need the release notes fixed inside the created Maven artefact(s). For this we copy the release notes from JIRA into ReleaseNotes.xml to produce a PDF with the docbkx-maven-plugin – a tedious, manual process.

So, I set out to automate a few things: get the release notes from JIRA and convert to DocBook – all programmatically. Continue reading “Release Notes with Groovy and JIRA REST API”

Leave the Selenium webbrowser open after a failed Cucumber JVM feature

When a Cucumber feature fails, Selenium quits and closes the browser instance. Quite often you want it to stay open to see what’s on the screen at that point to investigate what’s going on.

Looking for answers online I came across a lot of suggestions to put a breakpoint on the closing of Selenium or webdriver and run the test in debug mode, waiting on the breakpoint while you’re able to inspect the browser window. A more elegant approach I found over at bitcrowd without using a debugger!

Since it’s Ruby-orientented here’s a shamelessly copied and adjusted version for Cucumber JVM. Add the following file to your features/support directory:

public void leave_window_open(Scenario scenario) {
    if (scenario.isFailed()) {

        System.out.println("Step failed. Press ENTER to close browser...");
        BufferedReader br = new BufferedReader(new InputStreamReader(;
        try {
        } catch (IOException e) {


Add the tag @leave_window_open to the feature you want to investigate:

Feature: Dates with different date formats
 This feature shows you can have different date formats, as long as you annotate the
 corresponding step definition method accordingly.

 Scenario: Determine past date
  Given today is 2011-01-20
  When I ask if Jan 19, 2011 is in the past
  # here comes the failing step

Now, the step fails, but the selenium browser window stays open. When done, just hit return in the console you used to fire up Cucumber and it’ll finish as usual.

Thanks bitcrowd!

Using Jenkins Build Version With Maven

Knowing which version of your application has been deployed on a certain environment is essential for today’s software development and maintenance. Have you ever needed to support a customer which reported a bug in a feature for which you already provided a patch in version control? That you asked yourself why the heck that fix isn’t on production and you don’t even know where or how to verify this?

There are many ways of versioning (which by itself is a very broad concept) your software but a simple mechanism to track what’s being deployed could be;

  1. Use a buildtool (e.g. a continuous integration server such as Atlassian Bamboo or Hudson/Jenkins) to create your build. Use it to relate the build with the changes and code in it.
  2. Identify the version and make this visible in the application.

You don’t create builds from your local workspace these days, do you? 🙂

Below a simple outline of achieving this with Jenkins, creating a Mavenized webapplication (WAR), passing along a build number and reading it back in application code e.g. a JSF backing bean.

Using a build number

Define a property in your Maven pom.xml which holds the build number which we can overridde externally later on:


Create a manifest

If your application is packaged as a WAR (<packaging>war</packaging>) you can instruct the Maven War plugin to create a manifest file. This is a META-INF/MANIFEST.MF file which we can pass along some meta information about a JAR or in this case, the WAR.


You could leave out some stuff, but the essential part is Implementation-Version which uses the ${build.number} property. This will create a MANIFEST.MF which sort of looks like the following:

Manifest-Version: 1.0
Implementation-Version: SNAPSHOT
Built-By: jenkins
Build-Jdk: 1.6.0_31
Specification-Title: Example Project Name
Created-By: Apache Maven
Specification-Version: 0.0.1
Archiver-Version: Plexus Archiver

If you don’t overridde build.number it’ll default to SNAPSHOT. Well, for now this doens’t add much value, but now we can have Jenkins set it for us too.

Jenkins Environment Variables

If you would translate the above mvn commandline to a Jenkins Maven job you can use several of Jenkins’ environment variables to pass along in properties. E.g.

  • BUILD_NUMBER – The current build number, such as “153”
  • BUILD_ID – The current build id, such as “2005-08-22_23-59-59” (YYYY-MM-DD_hh-mm-ss)
  • SVN_REVISION – For Subversion-based projects, this variable contains the revision number of the module.

You can take anything from the list (if applicable, such as SVN_REVISION when using Subversion) and pass it along as property. Let’s take BUILD_NUMBER as our build.number property: mvn clean install -Dbuild.number=${BUILD_NUMBER}

In Jenkins it would look like

Jenkins Maven Build With Properties

If you would run the Jenkins job again, its current build bumber would be used and end up in the manifest file.

Manifest-Version: 1.0
Implementation-Version: 153
Built-By: jenkins

Reading the version

To wrap up, you obviously need to make this version visible in a running application. You could add the version to the HTML header in comments or display it on some sort of health page. For working with manifest files you can read the Java Manifest Files Tutorial. To read from it use java.util.jar.Manifest and java.util.jar.Attributes as you can see in the (JSF) example below.

ExternalContext application = FacesContext.getCurrentInstance().getExternalContext();
InputStream inputStream = application.getResourceAsStream("/META-INF/MANIFEST.MF");
Manifest manifest = new Manifest(inputStream);

Attributes attributes = manifest.getMainAttributes();
String version = attributes.getValue("Implementation-Version");


There’s obviously more to it than meets the eye…or your requirements. You can now see which build of the application is running on a environment, and going back to your CI server – which generated the build number – and relate it to the code inside the build. We haven’t used Maven’s own project version, release plugins or other fancy tools yet, but if you start simple you can always expand into more elaborate schemes to suit your needs.

GWT Compiler Is Running Out of Memory

As part of evaluating an open-source framework which uses Google Web Toolkit I ran into some of the familiar issues I already had a few times earlier with the GWT (GWT 2.4 or 2.5) Maven plugin compilation running out of memory. You know, when you see…

…at the start:

[INFO] #
[INFO] # There is insufficient memory for the Java Runtime Environment to continue.
[INFO] # Native memory allocation (malloc) failed to allocate 32744 bytes for ChunkPool::allocate

…or during compilation:

[INFO]    Compiling 12 permutations
[INFO]       Compiling permutation 1...
[INFO]       Process output
[INFO]          Error occurred during initialization of VM
[INFO]          Could not reserve enough space for object heap

This post is basically a compilation of the answers found online, and a quick reminder for myself and others who are running into similar problems with the fantastic GWT compiler :-).

1. First of all, check if you actually need to compile everything! Skip some browsers or locales – saving all kinds of permutations – if you don’t need it for development. Use the tips about how to speed up the GWT compiler and GWT compilation performance. There’s also an existing FAQ about GWT Debugging and Compiling.If you have control of your machine, cut down on other running applications and processes while you’re compiling.

2. Pass along some more memory

…to Maven, e.g.:

MAVEN_OPTS=-Xms1024m -Xmx1024m -XX:MaxPermSize=256m

…and/or to the gwt-maven-plugin, e.g.:

  <extraJvmArgs>-Xms768m -Xmx768m</extraJvmArgs>

You’ll have to play a bit with the values, depending on the machine you’re working on and the actually available working RAM.

Add some permgen space, which is used when GWT compiles Java into Javascript. E.g.


3. Try lowering the number of workers to a number explicitly below your available cores/cpu’s. If this number isn’t defined explicitly, the gwt-maven-plugin will set these to the number of available cores/cpu’s. Less workers = less parallellisation = less memory overhead.

  <extraJvmArgs>-Xms768m -Xmx768m</extraJvmArgs>

4. Try having the “workers” work in threads, instead of spawning new processes.

  <extraJvmArgs>-Xms768m -Xmx768m</extraJvmArgs>

Hopefully this will save someone some valuable time finding solutions. If you have other options, feel free to add them in the comments.

Create a free website or blog at

Up ↑