One of the challenges I have seen teams struggle with nowadays is versioning their packages. One of the problems with adopting any versioning system is that typically you have to version (at least) 2 components: the binary you are releasing AND the source code, at the time you have built the software. Doing this allows you to easily match versions in production to the source code — which needless to say makes it so much easier to diagnose things.

In the Java world this becomes an even more interesting problem as the binary can be versioned based on a naming convention (package-1.2.3.jar) as well as via the manifest file. Luckily there are a lot of plugins which can help you with versioning the jar filename — and equally it’s pretty easy nowadays to generate a manifest at build time which contains the same information.

The reason why jar versioning is important is to avoid clashes in the classpath — imagine if all the Guava versions were all produced as guava.jar for instance! On the other hand the reason why manifest versioning is important is because you can programmatically read it — say to report it back to a centralized point where you can aggregate this data and monitor if any of your servers are running unusual versions of libraries. And for doing so often you have to read your own manifest file and find the version.

And this is how I came up with this piece of code that others might find helpful: