Dr. Axel Rauschmayer is a freelance software engineer, blogger and educator, located in Munich, Germany. Axel is a DZone MVB and is not an employee of DZone and has posted 246 posts at DZone. You can read more from them at their website. View Full User Profile

Use a Single Version Number for Ant and Java (Bonus: GWT)

07.12.2010
| 6272 views |
  • submit to reddit

Problem: If your application has a version number, it should be accessible during runtime from Java (e.g., to display it in an “About this application” dialog) and during build time from Ant (e.g. to include it in file names). The solution is as follows.

Access the version from Java

Create the following properties file src/de/hypergraphs/hyena/core/client/bundle/BuildConstants.properties and put it into the class path.

    buildVersion=0.2.0
Access BuildConstants.properties as a Java resource. I usually construct the resource path relative to a Java class (a sibling of the file). That way the path to the properties file will always stay up-to-date, as long as I move the Java class with it.

Ant

Ant can read external property files as variable with the following statement.
    <property file="src/de/hypergraphs/hyena/core/client/bundle/BuildConstants.properties">
Additionally, you can insert the value of $buildVersion into a file while copying it, by using a filterset.
    <copy file="${data.dir}/index.html" todir="${version.dir}">
<filterset>
<!-- Replace @VERSION@ with the version -->
<filter token="VERSION" value="${buildVersion}">
</filterset>
</copy>
GWT

For client-side GWT, you can use constants. Then the version number is compiled directly into the JavaScript code. To do so, you add the following interface as a sibling of BuildConstants.properties.
package de.hypergraphs.hyena.core.client.bundle;

import com.google.gwt.i18n.client.Constants;

public interface BuildConstants extends Constants {
String buildVersion();
}

From http://2ality.blogspot.com/2010/07/use-single-version-number-for-ant-and.html

Published at DZone with permission of Axel Rauschmayer, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Ilja Brest replied on Mon, 2010/07/12 - 3:52am

Ok, but this is only a small part of version management. What about automation of version change in build and release processes? And what about maven (and maven release plugin)?

 

Thomas Eichberger replied on Mon, 2010/07/12 - 4:52am

@Ilja, this article isn't about version management, it's about how to have a single source (i.e. a properties file) for the version number and use it in Java, Ant, and GWT. That's the scope of this article.

Fabrizio Giudici replied on Mon, 2010/07/12 - 5:21am in response to: Ilja Brest

With Maven you can do the same thing - i.e. having properties expanded in filtered resources. You usually expand the ${version} label of the artifact (usually the main artifact, which gives the version of the project) that is automatically managed by Maven. This means that if you're using the maven released plugin you're fine.

Alessandro Santini replied on Tue, 2010/07/13 - 7:39am

My guts feeling is that making a software aware of its build number/version is not necessarily a good idea. I already see hordes of evil developers writing their own nice "if" statements against the version number.

I might be completely wrong, but I see the version/build number as an "external" - and most importantly - a static property of the system, in that it should not risk to become a criterion to drive the software behavior.

I think that Ilja was curious to understand the end-to-end story of this - in other words, how to automatically use this version number to tag a baseline in the SCM of choice.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.