The latest expert opinions, articles, and guides for the Java professional.
This is not another Maven rant nor intended as a flame war–we could even think of this as an “anti-rant”, if you like. I didn’t even bother to see how many other dozens of blog posts on this subject have been written. But let’s face it, one of the most commonly ranted-against tools in the Java development industry is Maven. According to recent results in our 2012 Developer Productivity Report (check out our really popular 2013 version too), Maven is the #1 build tool used by developers.
So what is a build tool supposed to do? Basically, it should automate a bunch of processes that developers need to do regularly, removing some of the manual sting from compiling your source code, packaging and running tests on it, etc.
Let’s start by reviewing the top 5 things that a Build Tool should do really, really well:
- Manage dependencies
- Be capable of incremental compilation
- Properly handle compilation and resource management tasks
- Easily handle different profiles
- Be adaptable to changing product requirements
I asked, “Doesn’t Maven do all this?” The answer, of course, was “It depends”. Since nothing is ever as simple as it seems, I asked some of the engineers at ZeroTurnaround in a live chat to rationally explain the good and bad of Maven to a non-developer like me. I’ve found that this exercise encourages developers to think through their issues a bit more carefully, and let me parse their replies to exploit any holes in their arguments.
I compiled (pun intended) their points into this blog post, which they have no idea would be published thusly, for your reading pleasure.
Stuff that developers, when pushed, say they love about Maven
It was a bit hard to pull this info out of our team, since they had to look way back in time to the before-Maven days. But we got the ball rolling once we agreed that Maven did some awesome things at the start:
- Goodbye huge libs! One of Maven’s most disruptive features at the time is that it removed huge libraries from the repository itself and pushed it all into a central repo, something that Java was seriously lacking before then. Today Maven central is the de facto repository for Java artifacts.
- Dependency Management FTW. The thinking is that Maven’s biggest contribution was the introduction of dependency management (with transitive dependencies). Maven was created mainly to solve the dependency management problem that existed in basically all other build tools at the time, and the tools we used today–e.g. Ant+Ivy, Gradle, SBT, Buildr and Tesla–all use the dependency repository that Maven introduced (other build tools had a chance to learn from Maven’s mistakes as well).
- One line at a time. Maven also introduced the concept of archetypes that could start up new projects with a single line of script, and when this is done through the IDE you don’t even need to write the rather verbose command yourself.
- Legacy and plugins. Maven’s plugin based so is designed for everything and anything–even things that build tools were never intended to do are possible with Maven, such as being used to start/stop servers and deploy apps!
Final point: Maven brought tremendous gains to Java with declarative dependency management, build by notation and the central repository back in the day, and other contemporary build tools, like Gradle, are based on the strong foundation that Maven built up over the years. Basically, without Maven, we wouldn’t have the vision and direction to make things better today. Anything–from industry to company to tool to individual–can always benefit from admiring the thought leader of yesterday and building upon their deeds tomorrow. Cheesy, I know. But true.
Stuff that developers voluntarily say they hate about Maven ;-)
“I don’t hate Maven, at least no more than other tools” – Erkki (@t4ffer)
Can we agree that every build tool will arouse disappoint and ire in developers at some point? So let’s get a few of the most important complaints out of the way here–let’s calls these “the top things that suck about Maven”:
- Not done downloading yet? Maven automatically downloads huge libraries of stuff, but you have no idea what the size is going to be so you just sit there waiting while your little rainbow wheel crushes the internets before your very eyes.
Devs should work on the code, not the build tool. Geert wrote that the most important issue boils down to Maven getting out of your way so that you can actually work on the product and not battle with the build tool. It seems like Maven sometimes works against the entire idea of what build tools are typically used for: building your product in ways that are specific for what it needs. If you stick to the Maven archetypes, you’re mostly fine, however as soon as you step just one fraction out of it, you spend the entire day searching how to do it and often not even finding how.
Hard to add custom build steps. Maven’s default settings are rarely enough for your needs, but if you want to add a few custom build steps you need to go through a horribly bloated configuration. Because the build lifecycle is mostly fixed, you have to stick your custom steps into weird places–although we remember an earlier version of Maven that seemed to be more friendly for custom build targets. But there is no easy way to import “aspects” or “modules” into your build–you can extend from other projects but that has the typical “single-inheritance” limitations.
Automation pains. Often you can’t really automate the build logic of your product and if you do, you have to either strictly adopt what the build tool supports or constantly deal with corner cases. Very true with Maven.
DSL vs XML. Although some of us have only started scratching the surface of Gradle, we’re starting to think that a Domain-specific Language tool is gonna beat out XML tools like Maven in the future. What developers really need is a language to describe the build logic, which is where a DSL can be nice. This seems to nicely combine the promise of Maven, which gives you ‘happy path’ instant project setups, with easy-to-write custom hooks and maintainable custom build logic.
Final point: We’ve come a long way since Makefiles, and no build tool is perfect. In the same way that Eclipse is the most-used IDE out there, Maven will have a long line of critics simply because of the population available. Already we see that DSL tools are where developers are looking to go in the future as programming language and application complexity continues to advance. Customization, automation and lightweighted-ness are necessities for any software now, so if a tool isn’t rocking out on at least 2 of those levels then it’s not going to make too many friends.
Oh, and Maven founder Jason van Zyl recently introduced Tesla.io, a polyglot DSL build tool that holds a lot of promise, even improving on his own famous pom.xml.
The developers that contributed to this piece thank you to leave feedback below, or tweet at @ZeroTurnaround.
Leave a comment