Don Brown: Fixing Maven 2

Don Brown is employed at Atlassian (vendor of JIRA and Confluence) and part of the Apache open-source community. He recently submitted patches for Maven 2 to "make it not suck". Enjoy the interview.

Q: Hey Don, you recently made some headlines by making a number of improvements to the core Maven 2 code base. What did you do exactly?

A: I created my own branch of Maven 2, -db, that included patches that added support for:

• HTTP connection pooling
• HTTP timeouts
• Asynchronous retrieval of artifacts
• Specific plugin versions tied to the Maven release

The first two features were provided by my colleague James Dumay, which fixed the HTTP wagon. The "wagons" are the modules that handle retrieving artifacts and poms. Unfortunately, the default HTTP wagon that is shipped with Maven 2 is the Lightweight HTTP wagon, which uses the limited HTTP capabilities of the Java java.net package. I figured out a way to bake the HTTP wagon into my Maven build so I got connection pooling and pipelining for free. These features gave about a 10% improvement in my build times.

The asynchronous retrieval of artifacts is a feature I wrote that implements a thread worker pool within Maven to pull down multiple artifacts at a time. You'd think that the limitation in that process would be bandwidth, but my tests showed a pretty consistent additional 20-30% improvement.

The last feature is part of an effort I'm starting to make builds more consistent. More info on my blog, but I think if your build builds with a specific version, such as Maven 2.0.8, it should always build with that version. Unfortunately, right now, Maven 2 tries to update its plugins automatically, which is rarely what you want. You can specify the plugins by adding hundreds of lines of XML to your POM hierarchy, but in my opinion, it should work correctly out of the box.

Q: What were your motivations for improving Maven?

A: In a nutshell, make Maven not suck. From a user's perspective, Maven 2 just gets in your way too often, whether it is breaking your build due to a new plugin somewhere or hanging due to a broken repository or network connection. My goal is to create a build of Maven 2 that does its job quickly, consistently, and with minimal effort. In my opinion, the best build system is one that you barely know it is there. My whole team shouldn't have to be experts in Maven just to consistently build a simple project.

Through my Open Source work at the Apache Software Foundation, I've been using Maven practically from the beginning of both Maven 1 and Maven 2. My current employer, Atlassian Software, decided to all but standardize on Maven 2, so now I deal with it every single day, and even though we have some very smart people, several dedicated to working on builds, we still see all sorts of problems and slow downs. It isn't even so much that the issues we see are Maven 2 bugs, but that the fundamental design of Maven involves so many moving parts, so many points of failure, that problems continually crop up.

To be fair, Maven does a lot of things right, and is a huge improvement in many areas from my trusted Apache Ant for large, multi-artifact projects. Therefore, I feel the answer is not to throw out the baby with the bath water, but get involved and try to fix it.

Q: Are you hoping to get your patches accepted in a future Maven 2 release or is this a fork?

A: As I list on my project page, I try to identify every change, its associated JIRA ticket and attached patches, and whether it was accepted or not. Some changes, like the artifact retrieval feature, are currently being integrated by a Maven committer, Brett Porter. Other changes, like specifying the plugin versions within the Maven release, won't probably ever be accepted due to philosophical differences with key Maven committers.

Therefore, I would definitely consider my version a branch, labeled "-db". The term "fork" carries many negative connotations that I don't think are accurate at this stage since: 1. The branch lives in the Maven sandbox 2. The docs live in the Maven wiki 3. I plan to keep merging back released versions into the branch

Still, and the end of the day, it is a one-man branch and therefore reflects one person's opinion on how to fix Maven.

Q: Do you have plans for more improvements? If so, which ones?

A: I do plan to continue to enhance Maven, having posted a list of desired enhancements since day one. I want to focus on fundamental changes that I think make Maven not suck, specifically, those that keep Maven out of my way. My inspiration for stability comes from Apache Ant, where I didn't have to worry about remote repositories on every build, self-updating libraries, network problems hanging my build, or super-slow downloads of little XML files. If I could combine Ant's stability and ease-of-use with Maven 2's declarative project definitions and superior handling of complex, multi-artifact builds, I'd be in heaven, or more accurately, ignore my build system to spend more time on actually writing code.

Q: What kind of feedback are you getting so far from Maven users? Are you also getting feature requests?

A: The overwhelming positive feedback has been the most surprising bit about this endeavor. I just wanted a faster, more stable Maven to use personally, and decided to blog about it as an afterthought. I've received a ton of comments (relatively for my blog, anyways), personal emails, instant messages, and have been stopped in the hallway repeatedly to talk about Maven, a project I previously only mentioned bracketed by curses. I've received many feature ideas and even a few assistance offers, a bit odd considering the Open Source project is pretty open. I think the whole "outsider's take" resonated with other developers who similarly feel personally tortured by Maven.

The positive support from the Maven committer community has been particularly surprising, considering the title of my first post. I think the very important difference between it and the previous "Maven sucks" posts is the willingness to do something about it, even if they do not agree with all my ideas. Open Source lives and dies, in my opinion, by the willingness of hackers to fix what annoys them.

Q: Given Maven 2's track record so far, what does its long-term future look like according to you?

A: For better or for worse, Maven 2 seems to be taking over Ant as the tool of choice for building large-scale projects. I believe Open Source tends to drive the technology adoption in the marketplace, because as more and more Open Source libraries are used to build enterprise software, their influence, including what tools are used to build them, spreads. Maven has been pretty well accepted in the Open Source arena, so I'd imagine its adoption will increase.

What people don't realize is the amount of knowledge you will need and the world of pain you are in for. I think Maven needs to re-evaluate its core philosophical approach to building software. My completely subjective impression is that it has too many moving parts, very intrusive, and is built by Maven experts, for Maven experts. I'd like to see a bigger effort to minimize the conceptual surface area of the project and cater to the common developer who really cares very little for what builds their code; they just want it to work and work quickly. My branch was created to explore exactly what that means and what trade-offs it will entail.

Thanks for the excellent interview Don!