a little madness

A man needs a little madness, or else he never dares cut the rope and be free -Nikos Kazantzakis


The Problem With Maven

Various times during the recent CITCON, the discussion turned to build tools. With lots of Java developers present, Maven turned up in most of these discussions. Like every build tool, there are things that people love and hate about Maven. The interesting trend in every Maven discussion is:

  • The people who love Maven love the theory. Maven defines and implements a highly-standardised build process so that if you are willing to follow that process you get a lot of stuff for free (plus the inherent consistency). This is a Good Thing, somewhat reminiscent of the in vogue “convention over configuration” mindset. Smart teams standardise their build process anyway, so why not take advantage by sharing as much of the implementation as possible?
  • The people who hate Maven hate the reality. The implementation just leaves a lot to be desired. Granted, taking on a larger scope than most build tools makes an ideal implementation more difficult. However, there are a couple of key implementation issues that cause headache after headache. First, there is a lack of flexibility. Small tweaks to the standardised model can be infuriatingly difficult to apply — frequently the only answer is to write a plugin. Second, there are major stability issues with plugins that are available. Some core plugins have historically been left in an unstable state for months.

Of course this split also creates many users that have a love/hate relationship with Maven: they love it when it works, and loathe it when it doesn’t. Users also spend a great deal of effort controlling their own Maven repositories to avoid some of the implementation headaches.

I don’t want this post to be taken as purely Maven bashing. The theory behind Maven is a valid one, and with some steps to resolve the implementation issues the project would attract and keep a lot more happy users. In my opinion, the project needs to immediately address the implementation concerns. Some ideas that come to mind:

  • A process needs to be put in place to control the stability of plugins. This must be a lightweight process that allows problems to be fixed and new versions delivered more quickly than in the past. Users also need more protection from unstable versions. If a new version is found to have a bug, wind back to a stable version so that the default plugin downloaded actually works.
  • The project could consider providing stable Maven “distributions” as pre-packaged downloads. Wrap these up out of battle-tested plugin versions.
  • Introduce at least one level of flexibility between “this is a simple config option” and “you’ll have to write a plugin”. I don’t pretend to have a magical answer for this problem: it is no easy task. But when a new user is trying Maven and finds some tweak will require them to write a plugin, it is a major turn off.

Make the reality smoother, and more people will buy into the theory.

Liked this post? Share it!

6 Responses to “The Problem With Maven”

  1. August 1st, 2007 at 4:31 am

    LES says:

    The problem is the learning curve. It’s steep. However, once you get it, you love it.

  2. August 1st, 2007 at 10:44 am

    Brett Porter says:

    Hi, sorry I didn’t make it out to CITCON as I’d intended – it seems like I missed all the fun 🙂

    You make some valid points. The issue of better plugin control is on the top of the list for the Maven 2.1 release. In the space of providing Maven “distributions” – this is one of the key reasons that DevZuz provide the Maestro distribution. On the last point I certainly agree – we see a lot of use of the “antrun” or scripting plugins at the moment to achieve this and it certainly could be easier through a more flexible lifecycle mapping.

    Thanks for the post!

  3. August 1st, 2007 at 8:26 pm

    Jason says:

    Hi Brett,

    Yeah, you should have come along, it was a good couple of days. Anyhow, it is good to hear that things are being addressed. No doubt I didn’t mention anything the Maven team didn’t already know. I just find it interesting that holy wars over Maven don’t focus much on the “religion” (i.e. the theory) as normally happens. The good thing about this is it is easier to improve the implementation than completely change your approach.

  4. February 19th, 2008 at 8:44 am

    The Joy and Sorrow that is Maven | Brugge Blog says:

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

  5. January 16th, 2010 at 11:34 am

    great-post says:

    “The problem is the learning curve. It’s steep. However, once you get it, you love it.”

    A build tool should not have a steep learning curve. It should be intuitive, and flexible. It should not make any wide reaching assumptions about how all projects will be because these assumptions are rarely satisfied in practice.

    Maven also encourages the developer to pile more and more logic into the build tool, to the point where the normal development cycle edit/compile/debug is negatively affected.

    Sadly, people are buying into it. It’s reminding me of large corporations that spend millions on “ClearCase” because they’re terrified (so the salespeople tell them) of losing all their code. In the end, nobody can use it because of network problems.

    Of course the salespeople tell you that “you just don’t understand it, but once you do, it’s great”.

    No, it should be simple and flexible. The fact that it has a “steep learning curve” is proof that there is something seriously wrong with it.

  6. December 14th, 2010 at 5:25 am

    koen says:

    You are so right !

    Next when you face maven lovers with reality, they start bashing about toy projects, proclaiming themselves the *real* developers.

Leave a Reply