Sunday, June 10, 2012

Why does Maven have such a bad rep?

There is a lot of talk on the internet about how Maven is bad. I have been using some features of Maven for a few years now and the most important benefit in my view is the dependency management.

Maven documentation is less than adequate, but generally when I need to accomplish something I figure it out once and then it works (for example when I implemented signing the jars). I don't think that Maven is great, but it does solve some problems that without it would be a genuine pain.

So, why does Maven have such a bad rep and what problems with Maven can I expect in the future? Maybe there are much better alternatives that I don't know about? (For example, I never looked at Ivy in detail.)

NOTE: This is not an attempt to cause an argument. It is an attempt to clear the FUD.

Source: Tips4all


  1. I looked into maven about six months ago. We were starting a new project, and didn't have any legacy to support. That said:

    Maven is all-or-nothing. Or at least as far as I could tell from the documentation. You can't easily use maven as a drop-in replacement for ant, and gradually adopt more advanced features.
    According to the documentation, Maven is transcendental happiness that makes all your wildest dreams come true. You just have to meditate on the manual for 10 years before you become enlightened.
    Maven makes your build process dependent on your network connection.
    Maven has useless error messages. Compare ant's "Target x does not exist in the project y" to mvn's "Invalid task 'run': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal" Helpfully, it suggests I run mvn with -e for more information, which means that it will print the same message, then a stack trace for a BuildFailureException.

    A large part of my dislike for maven can be explained by the following excerpt from Better Builds with Maven:

    When someone wants to know what Maven is, they will usually ask “What exactly is Maven?”, and
    they expect a short, sound-bite answer. “Well it is a build tool or a scripting framework” Maven is more
    than three boring, uninspiring words. It is a combination of ideas, standards, and software, and it is
    impossible to distill the definition of Maven to simply digested sound-bites. Revolutionary ideas are
    often difficult to convey with words.

    My suggestion: if you can't convey the ideas with words, you should not attempt to write a book on the subject, because I'm not going to telepathically absorb the ideas.

  2. It imposes rigid structure on you from the start.
    It's XML-based so it's as hard to read as ANT was.
    Its error reporting is obscure and leaves you stranded when things go wrong.
    The documentation is poor.
    It makes hard things easy, and simple things hard.
    It takes too much time to maintain a Maven build environment, which defeats the point of having an all-singing build system.
    It takes a long time to figure out that you've found a bug in maven and not configured something wrong. And the bugs do exist, and in surprising places.
    It promises much but betrays you like a beautiful and seductive but emotionally cold and manipulative lover.

  3. I've certainly bitched & moaned about maven in the past. But now, I wouldn't be without it. I feel that the benefits far outweigh any problems. Chiefly:

    Standardized project structure.

    Given a new developer joining a project:

    When you say it's a Maven project, then developer knows the project layout and how to build and package the project
    When you say it's an Ant project, then developer will have to wait for you to explain more or will have to go through the build.xml to figure things out.

    Of course, it's always possible to impose on company-wide standard with Ant but I think more often than not, you will be re-inventing the proverbial wheel.

    Dependency management.

    Not just with external libraries but also with internal libraries/modules. Be sure to use a Maven repository proxy server such as Nexus or Artifactory.
    It's possible to do some of this with Ivy. In fact, if all you need is a dependency management, you're probably better off using Ivy.

    Particularly within a project. I've found it quite useful to break out little subprojects, and maven handles this well. It's much more difficult with ant.
    Standardized artifact management (especially in conjunction with nexus or artifactory)
    The release-plugin is wonderful.
    The Eclipse & NetBeans integration is quite good.
    Integration with hudson is superb. Particularly the trend graphs for things like findbugs.
    It's a minor point, but the fact that maven embeds details like the version number inside the jar or war (not just in the filename) by default is tremendously helpful.

    The downsides for me are chiefly:

    The command line is quite unhelpful. This put me off a lot to begin with.
    The XML format is very verbose. I can see why it was done that way, but it's still a pain to read.

    That said, it's got an XSD for easy editing in an IDE.

    It's difficult to get your head round it in the beginning. Things like the lifecycle, for example.

    The definitive guide to maven is a good introduction however.

    I truly believe that it's worth spending a little bit of time getting to know maven.

  4. My practical experience from two large projects is that we have spent 1000 - 1500 hours for each project on maven related problems, excluding a 500 hour effort of moving from maven 1 to maven 2.

    Since then, I must say that I absolutely hate maven. I am getting frustrated when thinking about it.

    The Eclipse integration is awful.
    (We had endless troubles with code generation for instance, where eclipse got out sync with the generated code, and required a complete rebuild, quite often. The blame is both maven and eclipse, but eclipse is more useful than maven and say emacs, so eclipse stays and maven have to go.)

    We had a lot of dependencies, and as we discovered, syntax errors are actually commited to public maven repositories quite often, wich can ruin hours of your valuable time. Each week. The workaround is to have a proxy or locally governed repository and that took quite some time to get right, too.

    Mavens project structure is not really suitable for development with Eclipse, and the build time in eclipse increases.

    An effect of the code generation and sync problem, we had to rebuild from scrach rather often, reducing your code/compile/test cycle to an endless compile/websurf/sleep/die/code-cycle, sending you right back to the 90s and 40 minute compile times.

    The only excuse for maven is the dependency resolution, but i would like to do that once in a while, not in every build.

    To sum up, maven is as far from KISS as it can be. And also, advocaters tend to be the type of people that celebrates extra on their birthday when their age is a prime-numer . Feel free to vote me down :-)

  5. Maven is great. The reason for its reputation has got to do with the steep learning curve, in my opinion. (which I am finally close to getting over)

    The documentation is a bit rough to wade through, simply because it feels like there's a lot of text and new things to comprehend before it starts making sense. I say time is all that's needed for Maven to become more widely praised.

  6. Because Maven is a device for reducing grown men to sobbing masses of absolute terror.

  7. Pros:

    Dependency management. For several years already, my coworkers and I are not downloading and managing dependencies manually. This is a huge time saver.
    IDE-independence. It turns out, all major IDEs, Eclipse, IDEA and NetBeans how have decent support of Maven projects so our developers are not locked into one particular IDE.
    Command-line. With Maven, supporting simultaneous IDE and command-line configurations is straightforward which is good for continuous integration.


    Have to invest into learning Maven. Well, have to do it. Good news, not everyone on the team has to learn.
    Documentation. Used to be a problem, now thanks to Sonatype and their book (, the situation is much better.
    Rigidness. It is sometimes challenging and frustrating to do things the way you want. My advice would be not to fight and make Maven do things it does best, straightforward builds, or when there is a stable mojo available. In other cases, we drop out and do stuff either with Ant tasks ( orexternal programs. My personal favorite is Groovy plugun (


    Ant: doesn't have dependency management. Period.
    Ivy: still less mature than Maven (not that the latter doesn't have it's quirks, too). Almost the same feature set, so no compelling reason to move. I did several attempts to try it; all unsuccessful.

    Bottom line: all of our projects are done with Maven for several years already.

  8. My experience echos the frustration of many of the posts here. The problem with Maven is that it wraps and hides the details of build management in its quest for ultimate automagical goodness. This makes you nearly helpless if it breaks.

    My experience is that any problem with maven quickly degenerated into a multi-hour snipe hunt through webs of nested xml files, in an experience similar to root canal.

    I've also worked in shops that relied heavily on Maven, the people who liked it (who liked it for the "push a button, get it all done" aspect) didn't understand it. The maven builds had a million automatic targets, which I'm sure would be useful if I felt like taking the hours to read through what they did. Better 2 targets that work that you fully understand.

    caveat : last worked with Maven 2 years ago, it may be better now.

  9. Like Glenn, I don't think Maven has a bad rep, but a mixed rep. I have been working for 6 month exclusively trying to migrate a rather big project project to Maven and it clearly shows the limits of the tool.

    In my experience, Maven is good for:

    external dependency management
    centralized management of the build (pom inheritance)
    lots of plugins for lots of things
    very good integration with continuous integration tools
    very good reporting capabilities (FindBugs, PMD, Checkstyle, Javadoc, ...)

    And it has some problems with:

    all or nothing approach (hard to migrate slowly to Maven)
    complexe dependencies, intermodules dependencies
    cyclic dependencies (I know, bad design, but we can't fix 5 years of dev ...)
    coherence (version ranges don't work the same everywhere)
    bugs (again with version ranges)
    reproducible builds (unless you fix the versions number of all the plugins, you can't be sure you will get the same build in 6 months)
    lack of documentation (the doc is quite good for the basics, but there aren't a lot of examples of how to handle large projects)

    To give some context, there are around 30 developers working on this project, and the project has been around for more than 5 years, so: lot of legacy, lots of process already in place, lots of custom proprietary tools already in place. We decided to try migrating to Maven because the cost of maintaining our proprietary tools was getting too high.

  10. I think it has a bad reputation with people who have the most simple and the most complicated projects.

    If you're building a single WAR from a single codebase it forces you to move your project structure around and manually list the two of three jars into the POM file.

    If you're building one EAR from a set of nine EAR file prototypes with some combination of five WAR files, three EJBs and 17 other tools, dependency jars and configurations that require tweaking MANIFEST.MF and XML files in existing resources during final build; then Maven is likely too restricting. Such a project becomes a mess of complicated nested profiles, properties files and misuse of the Maven build goals and Classifier designation.

    So if you're in the bottom 10% of the complexity curve, its overkill. At the top 10% of that curve, you're in a straitjacket.

    Maven's growth is because it works well for the middle 80%