Maven sucks?

Kent Spillner certainly seems to think so. I disagree with the conclusion, but I find myself agreeing with a lot of the points he makes. It’s true that maven builds aren’t always consistent across different platforms or even maven versions. It’s also true that your pom.xml file can grow rather large and complicated if you want to get maven to do interesting things. And it’s definitely very true that maven dependency management can be hair-pullingly-complicated and is essentially broken. Sure.

But saying that writing your own build manager is better? Advocating ant and rake? Seriously? Maven does a lot more than just build your project. It does reporting, site generation, eclipse project generation and pretty much anything else you can think of. The convenience of the thing is worth a lot. It’s definitely worth having to struggle with the POM every once in a while. And to be honest, the POM syntax isn’t much more horrible than ant’s or rake’s.

As for platform/version inconsistencies: if you can’t force the people on your team to use the same software, then your problems probably run a lot deeper than just build management. Software has bugs, this includes maven as well. If you’ve hit a particular bug that causes your build to go kaboom, then fixing it sounds like the way to go.

If you have the time to write a build manager for every project you work on, be my guest. I for one don’t, and maven has actually served me pretty well so far.

16 Replies to “Maven sucks?”

  1. Hi,

    I read the same post yesterday and I disagree here too. Maybe there are some things about Maven which are far from perfect but that’s probably true for almost any tool.

    But in my opinion the main reason why most people hate Maven or try to explain why it doesn’t work for their project is that those people simply WANT to have trouble and create their own build tool for every project. And they want it to work THEIR way instead of conforming to conventions. Of course it soon gets messy if you try to use Maven but on the other hand you don’t want your project setup to use the Maven conventions. Maven simply wasn’t meant to be used in such scenarios.

    There are surely some things which get in your way at the beginning. And I needed a few tries myself until I could appreciate the benefits of a Mavenized project. I think you should at least provide a central repository manager (=proxy) to make the build more independent from an internet connection and more stable within the whole team, integration server, IDEs etc.
    The things in the POM which are annoying to create for every project can be refactored to a parent POM (which in turn can be deployed to the repository manager and reused by the team). The parent POM makes it easy to manage project dependencies AND plugin dependencies including versions in one central place. I don’t know why it should be better to use a VCS to manage project artifacts or extensions to Ant (and maybe rake)?!?

    But once setup correctly the benefits of Maven are huge in my opinion. Maybe others will disagree but I like the fact that I can just check out a project almost without any dependency JARs or build artifacts besides the POM and just open it in any common IDE, use the command line, a continuous integration server or other tools like Sonar without any change. It simply works out of the box with a good setup of the build infrastructure.

    That said, I definitely agree that Maven is not all perfect. But in my opinion the advantages outweigh the disadvantages more than enough. I have used it to build ordinary Java projects, WAR, EAR, EJB projects. I have used it to create automatic releases and assemblies. I have used it with external tools, the command line on Windows and Linux, with the three major IDEs and more. And i never had the feeling that it made things more complicated than build tools I know.


  2. I agree completely. Kent Spillner’s points were good, but his suggestions were abrasive in approach. About the third paragraph in he suggests to switch from maven to some other build solution and if you couldn’t, go somewhere else that will let you. Such a suggestion is not easy for everyone to follow. I was hoping to see a comparison of build tools but instead it leaned far to much on a rant about why maven sucks. I have used both maven and ant. Both can serve their purposes as a build tool. I believe it is more valuable to understand where their strengths lie instead of complaining about their weaknesses. Remember, it is not the tools we use which make us good, but rather how we employ them.

  3. Maven is effing broken. Period. It is the scourge of build tools and much like hair styles of the 1980’s should be summarily purged from human history.

    The real problem with it is the dependency management. Projects built with maven can end up 10 times bigger than what they would be otherwise. At best they end up 3 or 4 times bigger.

    Secondly the only way to get maven to do anything funky in your build process is to make it run an ant script, so why even go through the trouble of using it in the first place.

  4. The XML in a Maven POM may be verbose and for some details like plugin configurations it’s really inconsistent sometimes. At least in contrast to other tools a POM uses XML mostly in a declarative way. It’s good to have different ways for configuration in Maven 3 though.

  5. Maven’s greatness is in the Maven Central Repository! It may not be perfect (too many broken artifacts without the feature, which would allow to filter them), but is there any software repo in existence for other building tools which is nearly that good as Maven Central?

  6. @Justin

    Why do you think a project build with Maven should significantly vary in size compared to the same project build with Ant? You could even set up a private repository manager and deploy the same JAR files you’d use with an Ant project. There’s only one obvious reason to see a difference in size and that’s transitive dependencies.

    The good thing is that Maven shows you these dependencies (even graphical) and helps you to adapt dependencies to your needs. If transitive dependencies are optional and not really needed for your project you can just exclude them in the POM. Support for transitive dependencies i also useful to solve conflicts if different versions of the same transitive dependency are included by different direct dependency artifacts.

    Ant on the other hand simply hides these problems but it doesn’t solve them. There may be transitive dependencies which aren’t satisfied but the build may “accidentally” succeed because they are optional dependencies. Or the transitive dependencies are already include by other dependencies, so that you don’t notice they would be missing without this other dependency. And I’ve seen this scenario in more than one project where nobody really knows (or cares) about these things because it just works (at the moment).

    In my opinion the latter situation is undesirable. I personally prefer to know what I’m really doing. And if a project has complex dependencies then I prefer to deal with them instead of relying on some unknown side effects which may break the build some day without any obvious reason. Not to mention regular upgrades of dependency artifact which are then avoided because there’s always the risk to break anything if the needed dependencies are unclear.

  7. @Phil Swenson:: Because XML has been and still is the lingua franca of configuration. That may be changing, but you can’t expect existing tools to change overnight. Work is being done on this front.

    @Justin: If projects end up larger it’s not the fault of the build tool, but the developer who included all of th dependencies. If one doesn’t understand what transitive dependency resolution is, one should not be using Maven until that concept is crystal clear. Anyway, the same could be said about Ant and Ivy. Also, there are a multitude of configurable plugins to make Maven do things that are “funky.” If you don’t find one you like you can write your own in Java (Or another JVM language).

    Granted Maven has a learning curve and it’s far from perfect, but it has saved me hours. Unfortunately I’m always hearing people complain about how complex it is or how it’s “broken” Rarely are these people experienced users of Maven. I find that those that decide to educate themselves on the proper usage (there are plenty of free books/tutorials) tend to stop complaining.

  8. I have written a build tool in pure java that performs dependency resolution, SVN checkout/update, jars the classfiles, runs the tests. Each project has a very simple properties file that describes 4 things, the dependent projects (resolved relative to the repository root), the dependent libraries (with full path specified in a simple properties file), the (additional) resource directories, and optionally a jar file name.
    Nothing else is required.
    Circular references are excluded by standard Ant Project/Target code, checkouts by tmatesoft (or mercurial, hopefully, if we ever get there), compiler and jar utilities by sun microsystems.
    It is simple, fast, concise, and does everything we need.

    Should we require another utility, say an obfuscator, I can simply download the code, and call the code. No XML or weird shit.

    Since it doesn’t impose any structure, it works with ALL project structures.
    You may think it’s an advantage to force the Maven structure on all projects, but it’s a curse when you need to integrate with code that has a different structure, or use a tool that is not ‘Maven compliant’.

  9. One sign of software that is far too cumbersome and hard-to-use is that all the supporters of it have the broken-record refrain that the whiners are all just incompetent users. Come on, folks, if Maven really was that awesome, it would make things simple and easy to use from the first. But the things it’s supposed to make simple – dependency management, multiple sub-projects, automated build – those are exactly the things that users stumble over again and again. I’ve been using Maven for years now and often experience odd, upsetting difficulties with life-cycle surprises, dependency surprises, and the inability of Maven to understand dependencies of sub-projects in isolation from a huge, monolithic project build. It makes some things better, yes, but at the expense of a great deal of learning curve, random configuration errors, and very poorly-executed documentation and configuration cascade issues. Much is hidden and/or hard to troubleshoot.

  10. To add my 2 cents: My only real beef with Maven, and most free projects, is its poorly organized and ineffectual documentation. Basic questions have taken me much longer than it should have to find answers. And Maven is hard to use. It suffers from “it easy to use (once you know how to use it and get used to using it)” syndrome, which is not how I define easy to use. Developers should not defensively dismiss rants. Although ranters are ranting and “taking the piss out” they could be making valid points about real weaknesses of said software.

  11. Are you implying that non-free projects somehow have “better” documentation? I’m mildly amused by that 🙂

    Dismissing something, or ranting about it, because it’s seemingly “hard to use” seems counterproductive to me. Granted, parts of the maven documentation are crap or nonexistent. But the basic use case of maven (building a java project) is very straightforward. It’s a powerful tool, so it’s only natural that getting the most out of it takes some time and effort. Whoever said that software development was (meant to be) easy?

  12. @Bram

    A good build tool is meant to be deterministic. Maven is anything but. One day it works, the next day your build fails with some obscure message. If this has not happened to you then I don’t believe you have ever used Maven.

    When you say that “software development is not meant to be easy” – I agree. But it certainly is not meant to be made difficult by a build tool.

    I want to put time and effort into designing and developing my software and not into figuring out why my maven build failed – again.

    And why I have a terabyte worth of jars in my ~/.m2 directory.

Leave a Reply

Your email address will not be published. Required fields are marked *