Over a million developers have joined DZone.

Workarounds for five Maven 2 design issues

DZone's Guide to

Workarounds for five Maven 2 design issues

· Java Zone ·
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

Now that the Maven 2 hunting season has been officially opened here's my top 5 of Maven 2 design issues and their workarounds:

  1. Transitive dependencies: they are a liability. If your build consists of separate modules that are inter-connected you have to precisely design the content of these modules in order to control the dependencies that are propagated. Workaround: disable transitive dependencies by adding <optional>true</optional> to a dependency and add required dependencies manually.

  2. Plugins not shipped with Maven distribution: this is a design master piece according to some. Delete the contents of your repository and your build may no longer work. This is particularly an issue when you want to build an old version of your code, maybe some weeks or months old. Also, see next point. The Maven brotherhood regularly updates their plugins. Maven will automatically download the latest version unless you specify the version number in your pom.xml files. Workaround: specify plugin versions.

  3. Plugins are poorly maintained: we use the usual plugins and we have 4 (four!) different versions of commons-collection, junit and commons-lang in our local repositories, 3 versions of ASM and so on. All of these are dependencies of plugins. Many plugins are not longer maintained and it's not unsual that the latest version of a plugin has SNAPSHOT or alpha in its version. If plugins would be shipped with the product they would have to go through some kind of quality control and release cycle. Workaround: set up your own repository for plugins, change versions of dependencies in plugin pom.xml files.

  4. No distinction between JAR and project dependencies: if one project depends on another in the same build you should have the option to depend on that project, not its JAR. Furthermore, it should be possible to let Maven 2 automatically build other projects if you depend on them directly. Some people may be against this and this brings up a question: should the Maven brotherhood dictate our ways of working, or should they facilitate them? Workaround: none.

  5. Maven 2 is not designed to prevent loss of time: there is no charter on quality, no guidelines for plugin developers to work towards a better user experience. There's no oversight on plugins, not even the offical Maven plugins. Maven is extensible in many ways but not in ways that would make a difference. The code base is 10 times as big as it should be. The losers are Maven 2 users. We've already lost at least two man weeks on Maven over the course of a couple of months. Workaround: none, unless you want to write your own build system.

I believe Maven 1 has introduced a number of important practices. Maven 2 did not manage to go beyond that. In my opinion there's room for new build systems with a better focus on the user experience to replace Maven 2.

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}