Version of WAR after deploying

Question

I am currently building snapshots of a project using Java, Maven, Jenkins and Artifactory, and running the WAR on Tomcat.

After I copy a WAR file out of Artifactory into Tomcat and rename it, I have essentially "lost" the version of the application. I have two remote teams that are constantly dropping wars across integration machines and it very quickly becomes difficult to tell what is running where.

Eventually I would like to be able to query the app for it's version, or even just print out the app version into a log file at startup, but first I have to get the version into the war file itself.

I'm not entirely certain which entity is responsible for creating the version but it looks like it is Artifactory creating the SNAPSHOT version, like "myapp-1.2.0-20140514.145130-1.war".

The only solution I can think of is to stop using snapshots, increment maven versions manually at checkin, and then run a script that injects the maven version into a .java file before it is compiled. Yuck. Is there a way I can get this version into the app with my current setup?

Answer 1

This is a fairly common problem. In such an environment, with multiple teams and commits you might want to have more than just a simple version - namely who initiated this build, when and why/how. Take a look here: Job Exporter Plugin. It will output a nicely (Java friendly) formatted properties file that you can easily import into your application in order to get all the details about the job that was responsible for building and deploying that specific version of your app. Well, if you will implement this - there is no "out-of-the-box" mechanism to do so, you can write your own using regular Java APIs.

The other option is to use the Maven's plugins to do the effort for you. As it is a little bit more portable, it's actually harder to implement. One way to do so is to use Maven BuildNumber plugin. It can use timestamps, store build number in a properties files and do a lot of stuff... but it's local as this file should probably not to be committed. The other option is to rely on your repository (SVN, git or other) and get the last revision ID (i.e. with this plugin). It's handy as well, but it's not perfect and easy to read.

I would suggest to go with option 1 - the Jenkins plugin works great and you will get much more handy information. Just remember to read that file with an if-clause, so local builds can rely on something else or you will skip reading the file if it's missing...

---

Additionally, I have stumbled upon a plugin that does the extraction of your version from the Maven or SBT build process quite nicely - the Semantic Versioning Plugin. This does what is advertised - extracting the version from POM or whatever and including this as a file and a variable in your build process. So you have the freedom to use both, either include the file in your build process and do what you heart wishes AND/OR use the variable to affect the build flow in Jenkins. Now, because this plugin still have couple of bugs I would like to point you for now to my own build of this plugin with fixes already in that can be obtained from here. I will take my own version down the moment that all fixes will be merged to the official plugin...