In Defense of Maven
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?
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.
Entry Filed under: Agile and Development
- Agile and Development
- Application Modernization
- Cloud Applications
- Process Integration
- Technology + Healthcare
- Who We Are
Most Recent Posts
- Software Architecture: A Misunderstood Concept- Part #1
- Singletons CSS
- Calling Privileged Client .NET Code from a Web Application - Part 3: All the Myriad Technical Details – Build Steps 4 - 6
- Automating Database Updates in Spring Integration Tests with Liquibase
- Another Penny Game exercise showing the importance of synchronization and cadence
|« Feb||May »|