Home > Java > Maven doesn’t suck, your POM does

Maven doesn’t suck, your POM does

Maven bashing is an all-time favorite: there are plenty of articles telling how Maven downloads the whole Internet, or how POMs are bloated and so on.

While I agree that Maven could be perfected, I’m also aware that some (if not most) of its shortcomings are not intrinsic but are caused by (very) bad configuration. Worse, even if used correctly in your projects, problems sometimes come from third-party dependencies! You do not believe me? Well, two examples follow, from standard libraries.


Coming from the classic logging framework, this may seem a surprise but log4j POM is a mess. Just look at its dependencies section:


Interestingly enough, Log4J depends on the Java Mail and JMS API! If you are using your application in an application server, you may be in for a rude surprise as conflicts may arise between your dependencies and the libraries available on the server.

Moreover, while some users may have the need of mail or JMS appenders, this is not the case for all of us. As such, there’s clearly a lack of appropriate modularization in the design of the library. Luckily, the above POM is an excerpt of version 1.2.15. Version 1.2.16 uses the optional tag for those libraries (which breaks transitivity): it addresses our application server use-case but is still a problem for those needing the dependencies as they have to add the dependency manually. See here for a thought or two on optional dependencies.

If we need version 1.2.15, there are basically two solutions.

  • Clean but cumbersome: we have to manually exclude JMS and Mail from each POM using Log4J. Who said software development was fun?
  • Gruesome but effective: if we have a Maven enterprise repository, we correct the POM (i.e. we add optional tags) on the repository.

Jasper reports

The Log4J example was straightforward: just the side-effects of bad modularization. Jasper’s POM has another twist, just look at a typical dependency:


The version part means the dependency’s version should be between 1.02b included and the latest version. This obviously has two drawbacks:

  • From an architectural point of view, how can the POM provider guarantee there won’t be an API break with the latest version?
  • From a Maven POV, it means Maven will try to download the latest version. In order to do that, it will try to contact repo1… You’re beginning to see the problem? If you’re behing a corporate proxy that isolates you from the Internet, you’re toast.

The POM excerpt comes from version 2.0.4. Starting from version 2.0.5, Jasper’s designers used only single version dependencies.

If you’re stuck with older versions, the only solution here is to replace the POM with a manually crafted one that do not use unboundedversion dependencies on your enterprise repository.


Despite the constant noise on the Internet, Maven is a wonderful tool. Yet, even if I take the utmost care to design my POM, some external dependencies make my life harder. It would be better to stop losing time complaining about the tool and invest this time helping the developers of those dependencies to provide better POMs.

Send to Kindle
Categories: Java Tags:
  1. Christophe Vigouroux
    October 10th, 2011 at 08:25 | #1

    Hi Nicolas,

    For your problem involving Maven trying to contact repo1 to find the lastest artifact version and you being behind a proxy or using a custom repository, you can by example declare in settings.xml the following:

    my corporate repository

    Maven now contacts you own repository instead of repo1 (tested and approved on our private network not connected at all to internet but using our own nexus repo)… There is of course the drawback that this needs that each developper adds those lines to their settings.xml. And I don’t know if this works well with a filesystem repository ?

  2. Christophe Vigouroux
    October 10th, 2011 at 08:30 | #2

    Ok… WordPress doesn’t htmlencode automatically it just erases xml tags… So here is the configuration snippet again:

    <name>my corporate repository</name>

  3. Simon O
    March 26th, 2015 at 19:12 | #3

    “Yet, even if I take the utmost care to design my POM, some external dependencies make my life harder.”

    Sounds like the definition of a bad tool to me…

  4. March 26th, 2015 at 19:20 | #4

    Of course, by definition, a tool should read your mind, know what you want and deliver it on a silver platter. Most customers would surely agree with you, they expect the same.

  5. Simon
    March 27th, 2015 at 01:04 | #5

    @Nicolas Frankel

    Valid point re: customers, but what I meant is that a good tool should make your life easier and do everything possible to make misuse/abuse difficult.

    At the end of the day, even other developers can be idiots at times. Less common than users, but it does happen. Relying on everyone to get it right every time is guaranteed to fail eventually. Hell, that sums up Java in a sentence. It’s not flashy, it doesn’t have a lot of newer features and it requires more typing than almost anything else out there, but it’s reliable, scalable, dependable and relatively difficult to screw up.

    The pros often outweigh the cons in large projects where not _all_ developers are top calibre.

    So, you can make flippant comments about mind reading, but that doesn’t make Maven a good tool, merely an extremely powerful but unreliable one.

  6. March 27th, 2015 at 10:07 | #6

    Even if I agree that tools should ease your work, nobody can expect one to both offer security and usability – otherwise, cars would have been discarded long ago given the mortality rate. With great power comes great responsibility.

  1. No trackbacks yet.