In Defense of Maven

March 18th, 2013 Brian Gray, Consultant  (email the author)

Earlier this year, Neal Ford blogged about Why Everyone (Eventually) Hates (or Leaves) Maven. It’s a great read, but since not everyone will go the extra mile, I will attempt to sum it up grossly with this quote:

Contextual tools like Ant and Maven allow extension via a plug-in API, making extensions the original authors envisioned easy. However, trying to extend it in ways not designed into the API range in difficultly from hard to impossible

This is an oft-discussed topic among developers at Summa, the Java Posse Roundup, and Pittsburgh Geek Out Day. I have my opinion, and I figured I would put it down in “print” once and for all so I could refer to the article rather than re-hash it each time. A warning before we continue: this is just my opinion. I would and have recommend a variety of build tools.

I like Maven. I like it a lot. And I believe it gets a bad rap. And I believe those who have given it that reputation have done so not because they are ornery but because they are trying to make Maven into something it is not.

I completely agree with Mr. Ford’s quote that extending Maven in ways it wasn’t designed is difficult, and I’ve rarely seen it undertaken in practice. Where we disagree is that this is necessary or even desirable. Maven is not a programming language. It is a build tool. The build is essential to get right, but it is not what we are here to do. We are here to make the lives of our users easier by producing software, not writing fancy build scripts. What I love about Maven is that it IS opinionated and it is NOT easy to extend. It tells you how your code should be organized, what order steps should happen in, how frameworks should work together and so forth. When working with this tool, the developer’s job is to describe their software: how is this different from other software?

But many of the newer kids on the blocks (e.g. Gradle) can do that. So why would you choose a framework that uses XML and is complex to write plugins for?

As mentioned, I have used Maven on a number of projects. I have built Flex projects that integrate into Java projects, I have minified and concatenated JavaScript, I have compiled GWT and zipped it into an archive to be included into another project to be unzipped and used as JavaScript. I have had requirements that standard Java projects don’t have to do and I have never had to write my own Maven plugins. When I come up to a new challenge, get stuck or frustrated (and I do get frustrated), I stop and think, “How does Maven want me to do this?” “What is the Maven way?” And eventually I figure it out by using or composing existing plugins.

I find so often people who dislike Maven dislike it because it does not let them do things their way. That is not it’s goal. Maven wants to make the world of the build-master — a once chaotic and inconsistent world — and add some order and process. So that builds from one part of the company work like builds in another part, and even another company. And this does not happen if everyone does things their way, extending the tool as they see fit.

So in short, extending Maven is difficult. And I think that is ok. In fact, important. Because Maven is a build tool. And no one’s build is as special as they think.*

* Note: if your build is really special, as in you’re the first person to use a language or tool with Maven then yes, build a plugin. You are then establishing the Maven way of using that language or tool. And you release it for the rest of us.

Be Sociable, Share!

Entry Filed under: Agile and Development

2 Comments Add your own

  • 1. Chris Graham  |  March 20th, 2013 at 7:23 am

    In short (my motto for maven): work with the tool, not against it.

  • 2. Ashton Thomas  |  March 22nd, 2013 at 11:43 am

    Nice article!

    I’m sorry I missed the PGH Geek Out Day but hope to make the next one.

    Always good stuff from the Summa blog.

Leave a Comment

Required

Required, hidden


7 + = ten

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed

© 2010-2014 Summa All Rights Reserved