The Joy and Sorrow that is Maven

Published February 19, 2008 by John

In the world of Java development, the two top choices for build tools are Ant and Maven. Like Coke and Pepsi, or any other good two-headed field, the choice provides endless voice to discussions of which is better. What is interesting to me in the threads, though, is that when people praise or defile Maven, it’s often not an either/or sentiment, even when it’s passionate. When talking about Maven, it is not uncommon to both love it and hate it. And here I used to think I was the only one.

What’s to love and hate? The Zutubi guys summarize it well:

  • The people who love Maven love the theory.
  • The people who hate Maven hate the reality.

See? There you have it, two aspects of the same tool: something you can love, without having to dismiss the hate.

I’ve used both Ant and Maven on decent sized projects, and I can talk up the positive side of both of them. A basic Ant build can come together quickly, and you can have it grow as the project grows. A Maven build can come together quickly too, and when you add dependencies along the way and find that things just work, you start to take the lack of build friction for granted. Maven is great, you say.

However, I have also had to wrestle with each of them. The feeling of wrestling with Maven that makes it different, though, is that Maven can beat you. With Ant, you can work up some way around a problem, mainly because you’re working at a low enough level that the tools you have to work with are basic and well understood - copying, compiling, packaging, a whole bunch of simple and flexible tasks. It may not always be pretty, and the challenge (and not a small one) is to make this maintainable, but the slowdown in project work is usually on the order of hours.

With Maven, it’s a completely different story. You’re working both at a higher level of abstraction, and in descriptive rather than procedural form (”use these pieces to build my project” rather than “build this part of my project by doing A and then B.”) That means that you have much more leverage from small changes, but you have to know where to, and how to, make that small change. And therein lies what I think is the biggest rub for Maven users: you have the goal in mind, it seems like you are oh so close…and you can’t get there. You search the Maven docs, Google on terms or a stack trace message, look through the Maven books, and find nothing but crumbs. If you’re lucky some one else has had this problem, and if you’re even luckier there is a suggested workaround or solution. But just as likely is that you strike out, and have to troll through Maven debug logs looking for clues that you can understand.

You might say that this is nothing new to Maven, that debugging problems with any tool follows the same rules - use log files, Google, source code and forums, and get your hands dirty. And it is, but since Maven’s ambitions are so much larger than Ant’s you are in a much larger world of many more moving parts, with untold and varied ways that things can go wrong. Which is perhaps why I agree with a colleague who once said that Maven was great, when someone else is managing it. Once you start getting serious with what you expect, or want to get, from Maven, you better have a “Maven maven” on your team, or else be prepared for build breakdowns that are measured in days.

The other curious thing about Maven emotions are that people don’t “like” Maven or “dislike” Maven. No, the sentiments used are that you LOVE Maven, or that you HATE Maven, or feel both at the same time. Maybe it’s because Maven itself is big that the feelings it brings forth are big tool. Howard Lewis Ship’s “fool me once…” blog, and the ensuing comments, seem like a good example.

Lastly, one of the points often made when calmer heads enter the Maven and Ant debates is that Maven is much more than “just a build tool,” that it really covers a lot of project management ground as well. Describe your project once and you can have Maven both build your system artifacts and your project website, with information for end users, managers and developers. Heady stuff, but just like everything else in Maven, there is the theory and the reality. As someone who loves generating feedback reports from code, I have to admit that Tim O’Brien makes some good points about using Maven to create a project site:

So, I’m going to tell you what I think Maven is, and it isn’t the orthodox line: Maven is a build tool. Forget, “Maven is a project management system that allows you to cook, clean, and effectively leverage your synergies”. It’s a build tool, and if you really want to use it generate a site, go straight ahead, but, be warned, the sites it creates are pretty poor looking and customizing the presentation consists of applying CSS styles to poorly crafted mark up.

Your project’s web site is important, it is a central piece of the community you are creating, and this form letter approach to project documentation is no better than just relying on the default sourceforge project page. Here’s a helpful rule I’ve stumbled upon in documentation: if it isn’t worth having a human write it, it isn’t worth having a human read it.

Going beyond the project management parts of the site generation, there are also flaws in the documentation that we don’t want humans to write, the code analysis pages. Here, something sorely missing from Maven is a summary dashboard to be able to see the forest in the set of trees that you so easily planted with a few plugin descriptions. I love the fact that I can get PMD feedback for my entire project with a half dozen lines of plugin config. I hate the fact that I have to drill at least two layers down to see it. Maven 1 had such a thing, but it never carried along to Maven 2. Andy Glover sagely pointed out once at a JUG meeting that people will be really excited by your code quality reports if you generate them, but only the first day you send them the link. If you can’t help people see more than raw data, you aren’t going to get far.

Maven will continue to seduce, thrill and disappoint me, I’m sure. It’s just a roller coaster ride that I wish I didn’t have to take.

Filed under Tools

Comments (1)

Comments RSS - Trackback - Write Comment

  1. Michael O'Keeffe says:

    John,

    Great post. I’ve been a knowledgeable user (I won’t say fan, that’s too strong of a word I think for the relationship) of ant, and have used make of course, but there’s always room for improvement shall we say? One day, I spent a few hours reviewing the various tools out there, and decided against maven basically because of the “love it/hate it”. The poor documentation is also a showstopper.

    The wrestling example is great - I’m an ex wrestler (high school) so the imagery of being outmaneuvered by your own build system is classic. I agree, with ant, with cvs, the perl quote “timtwitty” fits well. There are many ways to evaluate the quality of an open-source (or even proprietary) tool before taking the plunge, and these are some of the criteria I use.

    A few other hilarious, but very apt quotes I found from the links you provided. Perhaps someone should collect these and create some sort of book, or online version, of software humor, along the lines of a book I recall in college, of collected graffiti, or American slang, etc:

    http://fishbowl.pastiche.org/2007/12/20/maven_broken_by_design

    “We have a joke around the office, when a new hire is setting up their development environment for the first time. “Now we go to lunch while Maven downloads the Internet.””

    As an aside, I’m pleased to see some projects like vim, iText, and log4j, provide very solid documentation as paid for only, what a great way to support an awesome tool. It still meets my requirement of “good documentation”, but you need to pay for it.

    Posted May 9, 2008 @ 10:57 am

Write Comment