Steven has posted 36 posts at DZone. View Full User Profile

Don Brown: Fixing Maven 2

  • submit to reddit

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 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!

Published at DZone with permission of its author, Steven Devijver.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Mike P(Okidoky) replied on Wed, 2008/02/06 - 5:19pm

"Maven 2 seems to be taking over Ant as the tool of choice for building large-scale projects."

I haven't seen evidence of that.

"Maven has been pretty well accepted in the Open Source arena"

Just about every open source project I've seen says otherwise. The odd ball open source project I've seen that used Maven, just didn't work. Actually, I don't think I've ever seen Maven + an open source project work together out of the box.

I've worked at a place once, where I had a really nice and tight build process. Then they had to hire this guy. Instead of spending his time on making improvements on the product, he spent all his time making everything work with Maven. I think after 3 months he was gone. The build process was left complicated, convoluted, fragile, slow, and worst of all, noone understood it.

I'm normally very positive, it's just that Maven is one of the few things I really don't like.

To fix it, yes, it must be a system that's as transparent as possible. You want to be able to compile a project that hasn't been worked on for a long time, just like that, zero questions asked, zero issues, no excuses, no adjustment in the project files, nothing, nada. Un-archive project, download Maven, build, and that's that, now, tomorrow, 10 years from now. That can not be achieved if the build process uses a language that constantly evolves. Ant's syntax does not evolve, really, just new stuff is being added, and now that it is what it is, I don't think anyone is adding a whole lot of new things to it anymore. That means the build.xml will likely work with the latest ant 5 years from now.


Robert Hicks replied on Wed, 2008/02/06 - 5:23pm in response to: Mike P(Okidoky)

I have seen where Maven2 has been replacing ant. Since he used the word "seems" maybe the projects he was looking at were moving from Ant to Maven. I have been seeing more and more software projects start to use Maven despite its quirks.

You cannot compare Ant to Maven though and I don't know why people try. Ant is "just" a build tool. Maven is much much more than that.

Personally I am watching Ant+Ivy to see how that goes.



Martijn Dashorst replied on Wed, 2008/02/06 - 6:52pm in response to: Mike P(Okidoky)

I'm not sure which open source projects you looked at, but all the projects I've ever used that depended on ant were a true nightmare. The need to hunt down dependencies, no documented versions for libraries, custom build targets, convoluted properties setups, the list goes on. When a project depends on maven for a build, it is as easy as calling mvn install to add it to the local repository. Maybe I've been lucky, or maybe your evidence stems from years ago when all there was was a flaky ibiblio repository that was not reliable.

cowwoc replied on Wed, 2008/02/06 - 11:45pm

I prefer hunting down dependencies than putting up with the XML tsunami that is Maven. When will people finally learn that XML is not meant for configuration or batch files? It's too damn unreadable. XML is great for computer-to-computer communication and horrible for human-to-computer communication.

Justin Lee replied on Thu, 2008/02/07 - 9:27am

I use the maven ant tasks from my ant build files and it works very well. All the fun of auto dep management without all the shackles and hoops of maven. And no futzing with ivy trying to get it set up correctly. You can see an example of it here.

Martijn Dashorst replied on Thu, 2008/02/07 - 10:08am in response to: Justin Lee

I like the conciseness of the tags. Why can't this be integrated in Maven?

Wilfred Springer replied on Mon, 2008/02/11 - 2:59am in response to: cowwoc

I can't remember Don complaining about XML. (... and Ant is XML too, right?!?)

But if you hate XML, then you could always try this: Maven configuration done in YAML.

Doug Holubek replied on Mon, 2009/05/11 - 9:10am

At my current job we have a multi module java and flex project using maven.   I don't understand why I should have to run a mvn install during local development.  Why can't eclipse compile the only the classes I just changed.  If I change a couple of java classes and I want to run the web app in my local tomcat I have to run mvn install from the directory of the parent pom.  I've turned off tests, run off line - the maven build still takes a couple of minutes.  To incorporate a build step in local development is not ideal.  Does anyone have a work around for this?

jiji530 (not verified) replied on Mon, 2009/06/29 - 9:45pm

thanks for your post.perhaps you will like abercrombie ed hardy mortgage rates tiffanys ed hardy Is not it?

Dan Cristoff replied on Fri, 2011/02/25 - 3:53pm

maven 2 is a usefull tool for those who need it!Adidasi

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.