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) two 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.

You may also like: Welcoming the New Era of Java

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 that can help you with versioning the jar filename — and equally, it's pretty easy nowadays to generate a manifest at build time that 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 that 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:

URLClassLoader cl = (URLClassLoader) App.class.getClassLoader();
URL url = cl.findResource("META-INF/MANIFEST.MF");
Manifest manifest = new Manifest(url.openStream());
Attributes attr = manifest.getMainAttributes());
System.out.println(manifest.getMainAttributes().getValue("Implementation-Title"))