Maven Adoption Curve


This post is inspired purely on a comment from my colleague Walter about Maven.

Here’s the normal technology adoption curve (x=time, y=satisfaction):

And here’s the same adoption curve as applied to Maven:

All just in fun of course….


17 Responses to “Maven Adoption Curve”
  1. Eric Danker says:

    Kinda funny…but kinda true.

    We used to think that Maven was the cat’s pajama’s…but lately it seems to be mostly more trouble than anything. For smaller projects, it seems to behave, but for a couple of our large multi-module projects…it’s just broken. Maybe a more fair description would be Maven+”the plugins we use” is broken.

    Not really in the mood to go back to Ant…so for now, Maven it is.

  2. If you are still using it, what is stopping you from contributing fixes? Besides, there are simple solutions for both, downloading issues and unknown plugins breaking the build.

  3. Casper Bang says:

    Haha that’s awesome. The idea of Maven is great, the execution however… ehh not so much.

  4. Shamim says:

    Most of the time it’s very simple to fix the unknown plugin problem. However you can generate ant script from maven.
    mvn ant:ant

  5. John Smith says:

    “If you are still using it, what is stopping you from contributing fixes? Besides, there are simple solutions for both, downloading issues and unknown plugins breaking the build.”

    Because this fix to it is to make it use jars within your project and not use repositories. Fixes that correct this flaw in the concept aren’t accepted.

  6. Jeff says:

    That’s hilarious, you’ve captured the experience perfectly.

  7. I second the recommendation of Nexus and while you are at it introduce a company pom that controls the plugin versions you use and read the book.

  8. Tony says:

    In my experience, dissatisfaction with Maven is typically caused by a lack of understanding of how to use it. Case in point:

    “Because this fix to it is to make it use jars within your project and not use repositories…”

  9. JC Mann says:

    Maven is flawed in both its idea and its execution.

    Idea: Put your head in the sand and let Maven manage your dependencies. A build system must be repeatable and deterministic. Both of these requirements are not met once it relies on externally defined dependency declarations. Maven requires its users to relinquish control of their project dependencies, which is absolutely absurd.

    Execution: Any build system that can’t gracefully negotiate an upgrade of itself is poorly executed. Any system that can’t automatically recover from a data corruption of its local cache (repository) is poorly executed.

    Changing back to Ant was much more simple than I thought it would be. While switching from Maven back to Ant, I reassumed control of my dependencies, and I was shocked to see the impossibly long list of jars that I “required”.

    Use a build system that is simple, repeatable, and easily understood. Spend your precious time solving problems IN YOUR OWN CODE.

  10. Luke Nezda says:

    JC Mann –
    rm -rf ~/.m2/repository; mvn clean install
    That’s not too bad, though you may want to get a coffee for a “maven” (Alex’s new time unit ;)).

    Not sure what kind of skynet build system you’re looking for – ant doesn’t upgrade itself that I know of.

    And to assuming control of your dependencies, that directory that your ant script points to with all your dependent libraries in it is equivalent to a what maven calls a repository and you can define a local repository for your site as you’re probably doing ad-hoc with ant now. Sorry to hear you gave up on Maven – I bet you’ll be back.

  11. Bill Kratzer says:

    My issues with Maven are quite simple:

    1. Maven repository corruption seems to be frequent enough that I just simply do not trust it. I’ve seen this on many projects, on many workstation types, and many clients. It simply should not happen.

    2. I’ve seen many projects suffer from unnecessary “jar bloat” when using Maven. A skilled developer can always manage this problem much better — and it really isn’t the big time drain that the Maven-ites make it out to be.

    3. Having to rely on an external repository for downloading jars seems like an insane idea to me. I want my project and its dependencies to be under version control so that I can be 100% sure that I am building the same binary artifact each time.

    4. On many client projects, I have seen more people spending a lot of time with “troubleshooting Maven”. Instead, they should be writing code to solve real business problems.

    I suspect in five years we’ll be looking back at Maven the same way we all fondly look back at EJB 2.0. :-)

  12. Shaaf says:

    All but in “fun off course…”. I would agree with Bill.

  13. Luke Nezda says:

    Bill –

    1. The only time I saw a corrupted repository, it was because I ran out of disk space. Bad hard drive ? Windows maybe ?

    2. jar bloat: Usually using others’ code is better than re-writing it, but if you depend on jars you don’t need, that’s just laziness I guess and offly easy to remedy.

    3. This is what checksums should put your mind at ease using external repositories

    4. Not sure what to say here – it’s generally felt straight forward and well documented for me across many projects and environments.

  14. Björn says:

    haha, typical Java world to recommend a repository manager as a remedy. Yay, another layer on top of the zillion other layers. Yet another tool to learn. Fun times…

  15. Bjorn:
    Or get into the HeadsUp! betas ( which will take care of everything plus repository management in one app…

    Folk should realise that the “a skilled developer” who realises they do not need transient dep from a project dep can mark it as excluded – much easier to debug should the project requirements change. Always have a trail to follow – a dir of jars is no help to anyone next time you want to update a single dep in a tree of dependencies…