Being a fan of Continuous Delivery, identifiable builds, and Continuous Integration: I like to deploy web apps with a visible build number, or some other way of identifying the version. For example, having the build number on the login screen for example.

In the Maven/Java world, this is straightforward. Or at least I know the idioms. I struggled with this a bit while working on a Grails app,  and wanted to share my solution. There may be other, better, solutions, but the ones I found approaches that didn't quite work they way that I'd hoped.

My requirements were:

• To display a build number from my CI tool, where the number was passed in on the command line. In Bamboo, for example you might configure a grails build as
  -Dbuild.number=${bamboo.buildNumber} war
• To only change build artifacts and not any source files.
• To not misuse the app version, or change the names of any artifacts.
• To be simple and idiomatic.

I realized that that Grails itself changes the application metadata (application.properties) when it does a build. So I modeled this approach after code in one the gant scripts in the Grails distribution.
The steps are:

• Hook into a build event to add a property in to application.properties.
• Access the property using the gsp tag.
• Pass the value into the the grails war command using a Java property.

To create the event hook, create a file in your project/scripts directory called _Events.groovy that contains a method like:

eventCreateWarStart = { warName, stagingDir ->
    def buildNumber = System.getProperty("build.number", "CUSTOM")
    println("Setting BUILD_NUMBER to "\+ buildNumber)
    ant.propertyfile(
       file:"${stagingDir}/WEB-INF/classes/application.properties") {
         entry(key:"build.number", value:buildNumber)
   }
}

Then you can access the property with a GSP tag like this

<g:meta name="build.number">


And you can now display build numbers (or any other properties that you want to pass in from you CI system) in your Grails app. This worked for me with Grails 1.3.7. The only down sides are:

•  This works on a per-project basis (That is probably easily fixable)
• The properties that we set are hard coded. (this could be fixed with a convention  that iterates through all of the system properties that start with "build" for example).

I welcome any suggestions for improving this, or alerts that I'm using the entirely wrong idiom :)