Nicolas Frankel is an IT consultant with 10 years experience in Java / JEE environments. He likes his job so much he writes technical articles on his blog and reviews technical books in his spare time. He also tries to find other geeks like him in universities, as a part-time lecturer. Nicolas is a DZone MVB and is not an employee of DZone and has posted 217 posts at DZone. You can read more from them at their website. View Full User Profile

Managing POM versions

  • submit to reddit

This article won’t be long but could be a lifesaver. If you use Maven, how many times did you need to manually update POM versions in an entire modules hierarchy? For me, the answer is: “too many”.

When you project grows to include many Maven modules, releasing a new version can be a nightmare. Sure, you have the maven-release-plugin. It does many things under the cover but in some cases, I saw it fail. What do you do then? You manually change your POM version in your modules hierarchy:

  • the version of the module’s POM
  • the version of the parent’s POM

It’s not only a boring taks, it’s also an error-prone one. Imagine my surprise when I found the maven-version-plugin and its little jewel of a command line:

mvn versions:set -DnewVersion=1.0.1-SNAPSHOT

And presto, the plugin does it all for you, entering each module and changing the previous informations:

[INFO] [versions:set]
[INFO] Searching for local aggregator root...
[INFO] Local aggregation root: D:\workspace\Champion Utilities
[INFO] Processing ch.frankel.champions.license:license
[INFO] Updating project ch.frankel.champions.license:license
[INFO] from version 1.0.0 to 1.0.1-SNAPSHOT
[INFO] Processing ch.frankel.champions.license:license-check
[INFO] Updating parent ch.frankel.champions.license:license
[INFO] from version 1.0.0 to 1.0.1-SNAPSHOT
[INFO] Updating project ch.frankel.champions.license:license-check
[INFO] from version 1.0.0 to 1.0.1-SNAPSHOT
[INFO] Processing ch.frankel.champions.license:license-common
[INFO] Updating parent ch.frankel.champions.license:license
[INFO] from version 1.0.0 to 1.0.1-SNAPSHOT
[INFO] Updating project ch.frankel.champions.license:license-common
[INFO] from version 1.0.0 to 1.0.1-SNAPSHOT
[INFO] Processing ch.frankel.champions.license:license-generation
[INFO] Updating parent ch.frankel.champions.license:license
[INFO] from version 1.0.0 to 1.0.1-SNAPSHOT
[INFO] Updating project ch.frankel.champions.license:license-generation
[INFO] from version 1.0.0 to 1.0.1-SNAPSHOT

Give it a try, it’s a real powerful yet easy!


Published at DZone with permission of Nicolas Frankel, 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.)


Charlie Mordant replied on Wed, 2010/07/28 - 6:24am

 I was use to make a property in order to deal with this:

Parent code:

Module code:


Fabrizio Giudici replied on Wed, 2010/07/28 - 6:27am

Question: how does the module know which is its parent if the version is defined in the parent?

Jilles Van Gurp replied on Wed, 2010/07/28 - 12:49pm

With ant I would externalize the version in a properties file in the root of my source tree. Release would be change properties file, commit, tag. Done.

I never understood why maven has to be so tedious about versioning.

I experienced again first hand "version management" in maven today. It took me  close to an hour to convince my project with about a dozen modules and several dozen dependencies to not depend on junit and instead depend on junit-dep (which excludes hamcrest) and the separate hamcrest library.

Problem, we have several dependencies (internal and external) transitively pulling in junit as a dependency. Each of these needed an exclude. It took some dependency voodoo + maven enforcer voodoo to straighten that out. I had two senior devs on my team ready to throw in the towel (i.e. forget about hamcrest) and give up on this before I sorted this out.

In ant I would have deleted junit.jar and added junit-dep.jar and hacrest.jar in lib. Commit. Done. I never had dependency issues that I couldn't solve in 2 minutes before I started using maven.

Two lessons here: 1) maven dependency management can be tedious when you actually want to manage your dependencies 2) as a consequence our dependencies are effectively unmanaged (case in point the junit mess I sorted out today and the commons-logging mess I had to deal with a few months ago). We have loads of outdated or worse, unused, jars being pulled in by maven. Occasionally somebody sits down to manage this mess (i.e. me) but mostly people leave it as it is until it actually breaks.


Erik Van Oosten replied on Wed, 2010/07/28 - 1:34pm in response to: Jilles Van Gurp

Hi Jilles, if you want to globally exclude a library you have the following options:

  • use the dependency plugin iteratively and to find each and every recursive artifact that depends on it
  • wait till Maven 3.1
  • use version 99


Version 99 is a fake maven repository. See my blog for more details.

Charlie Mordant replied on Mon, 2010/08/02 - 8:03am in response to: Charlie Mordant


My last comment just works for entire project compilation.

You can add your <project-version/> property in your settings.xml file if you want to perform single-module compilation

Rehman Khan replied on Sat, 2012/02/25 - 3:47am


Thanks a lot for the tip. I had a project with a complex maven configuration (OSGi and several other plug-ins) which systematically refused to bump it’s version number. The plug-in you mention solves this very nicely.

Comment viewing options

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