Myths Debunked

Maven Myths Explained


“I’m having a hard time understanding all the Maven bashing that takes place these days,” begins a blog post by Maven enthusiast Joseph Hirn.

The standardisation Maven applies to all project builds, means that once a developer has gotten to grips with one Maven project, they can then understand Maven builds across the board. This is often cited as one of the ‘great’ Maven features by Maven fans. Indeed, Hirn begins his latest blog posting with a nod to this very feature, before going on to discuss and dismiss a list of frequently-cited reasons for choosing not to use Maven.

Firstly, Maven models all its projects in the Apache style, even if they are not webservers. Hirn acknowledges that all Maven projects do look like Apache projects, but to him – an experienced Maven developer – this is just an accepted convention. “When I looked at appfuse projects, they looked like Maven projects to me.”

Secondly, Maven only has four build stages: compile, test, install, package. Again, this is an issue Hirn acknowledges, but he proposes a solution, which is using another tool, such as selenium, for testing functionality. While tracking down and installing add-ons is additional work, according to the Maven website these build states were purposefully kept simple, so it would only be necessary to learn a small set of commands before you could start building. Whether this is a weakness or a strength, all depends on what you want from your build tool. This is also the perfect summary of Maven’s convention of the standard directory structure being five subdirectories deep. It may be a bug-bear to some, but in Hirn’s opinion it is a “good convention.” He isn’t alone here, the Buildr build system, Gradle, and the simple-build-tool for Scala all use this five subdirectories convention.

The claim that whenever you are building with Maven you should be connected to the internet in order to update dependencies is, for Hirn, exaggerated. It may be recommended that you use the internet once a day for a snapshot, but this can be disabled. Therefore, the internet is only a recommended resource and technically it is possible to build a Maven project without the internet – but how often do developers try and build any software, without using the internet?

Some developers dislike how Maven manages project dependencies in its own .m2 repository, which is not part of the application folder, and can make tracking and packaging development environments problematic. Hirn argues that this isn’t so much a project repository as a local repo for multiple Maven projects you might be working on. He suggests using a Maven Dependency Plugin to track which local repo files make up your individual project. Again, this is extra work, but whether it is worthwhile extra work, depends on your Maven project (and, arguably, how many Maven projects you are working on.)

Finally, he addresses one of the thorniest issues associated with Maven: its convention for automatically resolving its own plug-in dependencies and project dependencies. Or, as Hirn puts it, claims that “maven always downloads the whole internet…..even though you don’t want to.” This convention was one of the major issues fuelling Kent R. Spillner’s ‘Java Build Tools: Ant Vs. Maven’ rant. However, Hirn suggests a solution to developers suffering from this problem: Maven 2.0.9, which introduced the ability to specify default versions of the core set of plugins. Download Maven 2.0.9, and be sure to specify which plugins you want it to download. To Hirn, it is as simple as that. However, he does fail to mention that the plugins locked in the super pom in Maven 2.0.9, are only the plugins injected by the default lifecycles and some other common plugins, such as assembly and dependency. The remaining plugins are still open to random, non-user specified updates.

Hirn raps up his argument by pointing to Maven’s free and open source status, and all the hard work that has gone into creating this build tool. Maven isn’t perfect and one day it will be replaced, but its replacement will have benefited from the foundations laid by Maven. Even if Maven falls frustratingly short of the mark on occasion, there will be a build tool in the future that doesn’t. And, until then, if you’re not a fan of Maven, then Hirn has a simple solution: try a different build tool.

Inline Feedbacks
View all comments