Myths Debunked

Maven Myths Explained

jt
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.

Author
Comments
comments powered by Disqus