Maven buildtime and version creation

When you are building a brand new application, it is usually the time, to challenge the old principles and to conserve the good ones while replacing the rest.

My latest challenge was ... providing visible time of build and version of web application build with Maven. If you are now thinking "bah, that is just easy", you are right, because it is. But my path towards the solution presented in this post was not as easy and straightforward as I would have imagined, so I am presenting one hopefully simple instruction how to do it.

I was deciding whether to put the build time and application version into the MANIFEST.MF file or to use application's  properties file. I have chose to use a properties file because one was already present in the application, thus meaning to me considerably less code needed to write.

Main principle

I am going to use maven's build-in properties along with a properties file, which is going to be filtered. This process will fill in the informations I want (i.e. build time and project version).

There are basically three things you need to do in order to get application's version and build time into a property file.
  1. Create / modify template property file,
  2. add timestamp properties into pom.xml file,
  3. add filtering record into the build section inside the same pom.xml.

Property file

My properties file is called omega.properties, but that is entirely up to you, because the entire directory is filtered (in my example, you could just filter the one file).
The content looks like this:
version=${project.version}
buildtime=${my.timestamp}

Pom.xml

And this is how pom.xml looks like. The head was deprived of artifactId, groupId and packaging in order to be more transparent.
The most important parts are properties and resources. The second property is called "my.timestamp", but that is just my nickname for it and you can change it if you want as long as you change also the same value in the properties file, of course.
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <version>0.0.1-SNAPSHOT</version>
 <name>omega</name>
 <properties>
  <maven.build.timestamp.format>dd.MM.yyyy HH.mm</maven.build.timestamp.format>
  <my.timestamp>${maven.build.timestamp}</my.timestamp>
 </properties>
 <build>
  <resources>
   <resource>
    <directory>src/main/resources</directory>
    <filtering>true</filtering>
   </resource>
  </resources>
 </build>
</project>
Firstly, I define maven's propety "maven.build.timestamp.format", because there is no default for that, secondly I set build time into a variable (in my example "my.timestamp"), because you can not just put "maven.build.timestamp" property into the filtered file.

Outcome

And this is how the filtered file looks like after the build process.
version=0.0.1-SNAPSHOT
buildtime=10.12.2012 21.26

Conclusion

Adding version and build time into an application is a simple matter, especially when you are already using a properties file. Maven offers fairly simple, but not so intuitive way, how to include build time and version record during the build and it can be handy to have this information somewhere in an application.
I am not discussing means for loading a properties file into the application because it is very dependent on frameworks you use.

Note

The variable "maven.build.timestamp" is usable only since Maven 2.1.0-M1. You would probably need to run an ant task in previous Maven versions.

Comments

Post a Comment

Popular posts from this blog

Automatic jsp recompile on Jboss AS 7

Image
Most of the applications I work on are based on jsp's and usually run on Jboss AS of various versions. And even though the newer applications are maven based and run on Jboss AS 7, almost nothing have changed in a matter of development. At least I thought that nothing have changed, but that was only because my carelessness. When you are developing web tier, there is no compiler telling you what is wrong in the real time, you depend on syntax validation only. And that enables you to do a lot of small mistakes that usually end up with error 500 and a need to redeploy the application. But this is the case only until you discover the right configuration!
Read more

Password hashing in Java

I was recently asked to provide db based user authentication for a relatively application, which user primarily ldap user authentication. This nearly backdoor-looking feature is only for a handful of users which made it ideal for experimentation. I could have stored user passwords as plain-text and nobody else would ever know, but the one person that would know matters the most, me. Almost every application uses passwords for user autentization. Although in complex environment, you don't usually want users to have different password for every application, there are situations that needs different approach. And in those times, security shouldn't be taken lightly. Whether you are writing small intranet application, or full scale internet application, you should always protect your user's accounts, because a lot of studies suggest that majority of users use the same password for everything, so for these users, when one application falls, they all fall. That is the re
Read more

Running scripts written in Clojure as an executable using Inlein

Do you sometimes wish you could create a smart, yet still simple utility? My usual dilemma is choosing whether to create a shell script to suit my needs, or to create a standard Java application. Now I have another handy alternative. I was just shown an interesting program called Inlein . Inlein lets you to run Clojure written scripts without the need to care about its dependencies. This way you have all the libraries you could wish for at your disposal and yet the utility you are writing is an easily modifiable and readable text file.
Read more