The point is missed

Museum of public mistakes and unfinished projects

Why I don’t like Maven

with 17 comments

More than two months ago I tweeted something like “As if this day didn’t already suck Maven 3 was released”. I got a reply from @kirean73 “Mind sharing your experiences with Maven?”. Fair question. As it takes more than 140 characters I decided to write a blog-post about it. And since I did not have time to do it there and then I asked @kirean73 to remind me after a month had passed. A month ago I got the reminder but this post turned out to be really hard to write. Mostly because there is nothing seriously wrong with Maven…

I’ve been looking forward to write this post for some time. I really don’t like Maven but I realized that I don’t exactly know why. It will be useful to explore that. I don’t want this to be just another of the many maven rants out there. I’ll try to be fair but I also reserve the right not to think that some things are good  even if I can’t present a better alternative :) This is a subjective post.

I have yet to try Maven 3 though so things may have improved in that version.

When it comes to my experience with maven: My first experience with Maven must have been in 2004 or so. We investigated if we could use maven for a project we were starting. A few of us looked into it and found Maven to be a bit opaque “what does this thing actually do?”. Since then I have that part figured out of course but back then we stuck with our ant-script. That was probably the wrong choice. The feeling of an untransparent build-system still sticks somehow. I find that Maven is sometimes a bit hard to penetrate. I find that my maven usage is a bit google intensive and that maven is a little bit of a black box at times. I don’t know if it’s just me or if the Maven philososphy is a bit like “don’t you worry about your build, we take care of it. Just write mvn clean install and you’re good to go”. I’m outsourcing the details of my build to strangers.

I have used maven on and of through the years. Maven does a decent job most of the time. Can’t complain. Above all Maven gets you started quickly; just arrange a project so that Maven finds it’s way and your’re all set. Maven has also made wonders for the Java community when it comes to how to distribute your binaries. Before Maven there weren’t really any good options. In fact Maven is pretty decent over all so what’s the problem really? Maven stands in the way of innovation, Maven is not excellent, Maven assumes there is one right way to build for everyone, Maven does too much and sometimes bites off more than it can chew, Maven is hard to extend, Maven is a bit of a black box, Maven is slow, Maven is unreliable.

Ok, that was a lot of unfounded opionons. They all deserve to be motivated. I will explain what I mean with each of them one by one in reverse order:

Maven is unreliable

Ever deployed something you just built and found that for some reason your last change did not make it to the build? No? Good for you! An experience I know I share with many is that I build clean quite often with Maven. It happened a few times too many that I deployed something after a dreadfully long build-cycle just to find that everything was not in there in mysterious ways. Build clean, wait again.

I especially find Maven unreliable in combination with eclipse. The Maven plugin for eclipse can really mess up eclipse’s build-cycle. Infinite loops, persistent errormarkers that are never removed etc. You often get different results from the prompt and from within eclipse. It happened a few times that we had infinite loops of rebuilds in Eclipse (ok, I can’t prove that the loops were infinite since we did not wait for an infinity but we did see the same projects being rebuilt over and over again). The incremental build is about the only truly excellent feature of Eclipse and with Maven that pretty much goes down the drain. If there is one area where Maven really does suck it’s the eclipse integration. As usual though Maven gives you enough to make you think it’s worth the hassle. I’m not sure if it is.

Maven is slow

I heard that Maven 3 is more snappy. Good thing. Maven 2 is prettty awful performancewise. Why is that a problem? Slower builds, slower feedback. Slower feedback, worse quiality. Simple as that. Hardly anyone that use Maven does not know how to disable tests in a build just to make the build times bearable. While it’s fair to point out that most developers could learn a thing or two about how to make their tests run faster maven still has a pretty long ramp up time when it does not output any useful feedback to the developer.

Maven is a bit of a black box

This is one of my key issues with Maven. Partly the black boxyness is due to java as the language of choice for creating plug ins. In Buildr for example, if I want to know how something works I can just find the source and look at it (Buildr is made in ruby). If I get a stacktrace I can do the same. If there is a bug in the plugin I can fix it by editing the plugin source. If I feel like it, I can generate a patch and submit it so I won’t have to fix it again when upgrading.

While I can download the source for a maven plugin and do the same I also have to think about how to distribute my plugin to others after I figured out how to get the source and compile it. If I want to know how things work I will at the very least have to find the documentation for the plugin (if there is any good documentation to be found). Due to the maven strategy of plug-ins the documentation is fragmented and scattered.

Maven could compensate for this better. For instance when I run mvn –help it would be nice if I could somehow see what the build-cycle will look like. What will happen when. It would also be nice to get a listing of all pugins I have in my Repo and their options, heck, it would be cool if I could see a listing of all plugins available in any listed online repository. I bet there are plugins that can provide this information but then I would have to know about them. I could google but I think I should also be able to find out via mvn –help.

If I supply an option to maven like -Dmaven.test.skipp it would be pretty nice if Maven told me that maven.test.skipp is not a valid option. Why not tell me which options are available whenever I supply an unrecognized option? Sure, Maven can’t know which options plugins accept… or could it? At least maven could have been designed to be able to do this if it was considered important. But obviously it wasn’t… consiered important. Maven doesn’t even tell me about my alternatives when I run jetty:start. It would indeed be helpful to know my alternatives then and that one of them is jetty:run. In all projects that used maven I have heard a lot of questions among teammembers: “Do you remember how you do X in maven…”. We’re not talking about hard stuff. Just basics like how to run the integration tests. Symptomatic of an opaque system.

Maven is hard to extend

When it comes to plugins maven could do what SBT does. Just supply the source in the correct directory and they will be compiled when needed. It would simplify distribution, versioning of your whole build in one place etc. Of course with an interpreted language it all becomes even simpler and perhaps build tools should be done in interpreted languages (as is the case with Buildr and Gradle for instance). Given that the source is always available it’s much easier to learn those inner details that so easily get lost otherwise.

Maven does too much and sometimes bites off more than it can chew

I often feel that Maven is not satisfied with being my buildtool. It wants to be my whole development process. Maven dictates how I should do my versioning, packaging, deploying, directory structures you name it. There are very few areas of development where maven does not meddle. In this Maven sort of becomes a jack of many trades, master at none.  I think the maven plugin is what will kill Eclipse (ok, Eclipse wont die easily but the maven plugin totally takes over eclipse’s build and turns it into an average IDE from the early 2000s buildwise…). I often feel that Maven’s approach sort of works but is a bit dated and far too rigorous for the simple case… but hey… it sort of works so why complain?

Maven assumes there is one right way to build for everyone

I have to conform to Maven to a large degree and the compromise is always on my side. This is not by necessity a bad thing. The maven folks are right that all builds do essentially the same thing so why shouldn’t we standardize the process and solve it once and for all? To be honest, if Maven hadn’t beaten me to it I would probably have started (and if I know myself not finished) a project to create something like Maven. Maven’s idea makes total sense. The bad news is that there is no one true model for every problem. Even if it sounds totally crazy, the way you do your builds can be a competitive advantage. How you build is a key component to how you get your feedback and how often you can deploy. Your build tool is a strategic tool!

There are also ways in which Maven punishes totally valid choices. For instance in multi site it’s hard to get an aggregated view. If I chose to rely mostly on acceptance tests and not unit tests I can’t see how well every module in my system is covered by those tests. The test coverage reports with cobertura for instance are generated per module from the tests in each module. I cannot see how well module B is covered from module A. You may argue that this way of testing a system is not pure, good, cocher or whatever you call it but that would just be you imposing your opinion on everyone else. Maven should not make that choice for developers.

You may make the point now that it’s not Maven’s fault that the cobertura plugin works how it works. Fair, and it would be ok too if it would be a simple thing for me to adapt to my needs but as far as I’m aware there is no way I can express my needs in XML so that the cobertura plugin understands me. If it would be a simple thing to fix given that I have downloaded the source for the cobertura plugin I don’t know. Perhaps it’s in Mavens nature?

Another point is this thing with versions. What if I release every 10 minutes? I can really get a versioning nightmare in Maven. If I use snapshots for everything it can become a performance nightmare (so that I in efect can’t release every 10 minutes).

Couldn’t agree more that each build is not as unique as a snowflake. They all look pretty much the same from a long enough distance but so does snowflakes. Mavens build process works ok for everyone. Mavens process is optimized to suit average needs (and succeded quite well). On average Mavens model works well but it will just be average :)

All builds do essentially the same thing but the focus can make a world of difference.

Maven is not excellent

If Maven was the end of the road when it comes to builds; the ultimate one and only answer to how builds should be done then that would indeed be excellent. Unfortunately I doubt that there will ever be a one and only ultimate build solution out there. I have no doubt that Maven is a perfect match for some but I know it’s not a perfect match for everyone. It is all fine if Maven would recognize this but it doesn’t. Maven really tries to be the ultimate build solution and is bound to fail like every other tool that attempts this.

There are so many dimensions that you could optimize for and it’s highly unlikely that one tool would excel in all of them.

Maven stands in the way of innovation

Maven does a good enough job for most problems to have become popular. When a tool becomes as popular as Maven most people don’t even look at another tool. There are other initiatives out there that deserves more attention but teams play safe and choose the tool that everyone knows (though most people I have met know little more than how to type mvn clean install).

Maven is now an established tool. As such there is not much innovation happening at Maven’s initiative. Most new cool things like shells etc are created in other tools first.

I really can’t say why but I also have this strong feeling that the Maven team does not share my values when it comes to how I want to build my software. I have specific needs when it comes to testing, deploying etc. I don’t really believe in the one tool to rule them all idea.

If I’m going to outsource something as important as my whole build process to a team of people I don’t know I better feel that I trust that team to look after my needs. I don’t. Especially since the Maven team has already failed twice to create an excellent build tool. Why would they succeed a 3rd time? What indications are there that the Maven team learned any important lessons from Maven 1 and Maven 2 that will make Maven 3 the final one tool to rule them all?

So pardon me for not jumping up and sown with glee when I heard that Maven 3 was released. I’m sure I will find out soon enough just how excellent Maven 3 really is (wether I want to or not). As for my curiousity and learning that comes from it it is currently aimed at gradle and SBT.

I think Maven works fine but in the past some logical choices have been made that do no longer make sense (XML, a compiled language for plugins etc). Other tools have fixed those and it will be hard for Maven to change in fundamental ways (and Maven shouln’t, it does what it does). When I will have to use Maven I wont bitch about it but I will sure keep my options open. Will you?



Written by johlrogge

December 14, 2010 at 7:22 pm

Posted in build tools, java, PMS

Tagged with , , ,

17 Responses

Subscribe to comments with RSS.

  1. I like maven because of how it standardizes everything, especially when it comes to open source projects. With maven a new member can be contributing (compiling,testing,building,releasing,etc) quite quickly if they have used maven before. But for projects not using maven, its always different on how to compile, run tests, build, etc; some projects uses Ant, Makefiles and what nots. Also projects not using maven will organize their files very differently, so i would say maven is great for the open source community as it makes the step to start contributing smaller.

    Then I agree that I sometimes google too much to find out how I do things when using maven. Perhaps they need to develop a feature that helps determine what the user want if they enter the wrong argument. (Countless are the times Ive search for how to turn off unit tests on a build).

    But then again, what are the options? What other build systems exists out there that does a decent job? Ant is not a good system, as i always found that the scripts become more arcane as the project gets older. MSBuild is nothing but a colored ANT system. So, if I would start a new project what build system should i use? (i dont know)


    December 15, 2010 at 12:25 pm

    • Thanks for taking the time to read my wall of text and for taking the time to comment.

      I agree with you about some things. Maven does a very good job at getting you started quickly. Maven does a less good job when it comes to letting you go fast. It’s a bit like getting from 0 to 50 in 0s but never be able to hit a 100.

      Some of the standards can still be kept in essence even if we use a different tool than Maven. Standardization is definitely a good thing bit it has it’s downsides too. One thing that I think is becoming a problem is that things have gone a bit stale on the build tool front. Innovation need a certain degree of chaos. I don’t think the next step will be taken by Maven any more than it was taken by Ant when Maven came around. You could say things were pretty standard in some way before. You always used ant to build java code.

      About a feature that can gives some helpful hints when you write something that is not accepted would be a good thing. This is where I feel that the Maven team would have done this years ago if they found it important and quite a strong indication that we are not on the same page in the book of values so to speak.

      Ant is not a good build tool either. Sometimes I wonder what problem Ant was fixing. What was so horribly wrong with make to make the world prefer to write and maintain XML… I don’t know really…

      If there are no options we must create them. Luckily there are a few interesting alternatives out there. In particular I find that gradle is promising. Their mission statement addresses one of the biggest problems with Maven:

      “There is no one-size-fits-all process for builds. Therefore Gradle does not impose a rigid process over people. Yet we think finding and describing YOUR process is very important. And so, Gradle has the very best support for describing it.”

      You may want to check out Buildr for something more maven-like but backed by a dynamic language:

      Also SBT has some really cool incremental features that really makes a difference in ramp up time and feedback cycle:

      There are some options out there. The don’t have the best momentum yet but it looks like some will make it. SBT for instance is starting to become common in the scala commuity. Gradle looks like it may actually cut a piece of the java-scene.

      Among the more obscure tools:

      From what I understand it addresses the needs of clojure programmers and may not be a good choice for java-projects. I have not looked at Leiningen at all.

      For now it is maybe enough to become familiar with the alternatives out of curiosity while using maven at work. At some point maybe one of the alternatives comes out as a winner for YOU and you can make the switch.

      Hope this gives some inspiration.

      Hope this helps


      December 15, 2010 at 1:51 pm

  2. Good article.
    Mostly, I like the concepts of Maven, but the tool itself isn’t very great.
    What’s truly great is the dependency management, fortunately most other build tools available use a compatible dependency management system too. Another good if not great thing is the standardization of directory’s. I don’t agree you should or need a choice on that. But that doesn’t necessary have to be enforced.

    Note for self: Maybe now would be a good time to invest time into moving from Maven to another build tool while keeping the good things. I’d have to find out what build system first :-). Maybe Buildr or Sbt


    December 15, 2010 at 2:20 pm

    • I agree the concepts are appealing. Some of them may be poorly implemented and some work better in theory. I don’t feel strongly about changing the directory structure. I usually default to the maven style even if I don’t use maven. I must say though that I think that the structure is over engineered.

      Have a look at Gradle also. I heard it’s good.


      December 15, 2010 at 9:54 pm

  3. […] длинный и обстоятельный рассказ «Почему мне не нравится Maven»; […]

  4. Good article!

    I found so much in common with my own thoughts.

    Really, I also couldn’t figure out why I didn’t like Maven.

    But also I found that there’re a set of technologies that are too hard to start using properly in short period of time because of their complexity.

    Beside Maven, one of such kind of technologies is Java Generics. This is really simple if you just use some Lists or Maps, but when you start implementing your own generic-powered classes, things become harder than you expected them to be.

    The same thing with Maven – if you just compile and run tests, all you need to know is a couple of cmd commands. But if you’ve got to modify project’s build script (changing dependencies, or adding some 3rd party tool for deploying) then you realize that the reading of 5-step tutorial is not really enough.

    Maybe similar experience with RegExp. You need to understand all its concepts to start building even simple ans small expressions.

    So, the common disadvantage of all these technologies is that you need to read a lot of docs before start using them. But I guess we shouldn’t treat them as bad because of this.


    December 17, 2010 at 6:15 pm

    • Thank you!

      Very interesting comparison with generics. It is also a controversial technology where opinions differ quite a bit. I don’t think it’s as simple as the ones who do not like generics don’t understand them. There are philosophies in software development where generics (or static typing for that matter) simply don’t have a place.
      Same with Maven, many that understand Maven well don’t think it’s the right tool for them.
      You’re right though that this doesn’t make Maven a bad tool for everyone anymore than it can be a good tool for everyone. We tend to be way to binary in the software biz.


      December 23, 2010 at 9:58 am

  5. nice article..

    actually I nearly became ‘paranoid’ of being the only one who don’t like maven..since everybody is jumping to there.

    hence my google search “what is so good about maven” spew out your nice article…;)

    personally I prefer to meddle and ‘screw’ things around, it’s way more fun. but with maven… i really dun see how one can have much fun with it…

    yeah…it removes all the nitty-gritty…but nahhh…not for me


    February 6, 2011 at 2:04 pm

  6. thank god! not all intelligent people are dead yet! good to find someone who share thought.


    September 27, 2012 at 4:07 pm

  7. Anything (really anything at all) that takes 17 lines of code to copy a file from one place to another is insane. That’s the length of the XML configuration it takes for Maven to do this.

    I have to work on legacy projects that use Maven. I dread the days that I know this is going to happen.


    January 23, 2013 at 4:56 pm

  8. The choice to use -D property defines in place of command line arguments is incredibly cowardly. I have many thoughts on Maven, in fact I think its one of the most detestable tools ever to hit the Java space. Part of it is trust. I dont trust a build tool that fails a build then I run it again and it succeeds. Part of it is programming idiocy, how many times have you run a build in a day with Maven syncing down libs that it has no need to sync wasting your time spewing nonsense into your console? Part of it is layout, none of Maven’s business, I can write an ANT template for my projects layout in 15 mins that will endure until the sun burns out. Part of it is horribleness of definition, read that POM, make sense to you? Doesn’t make sense to many. Part of it is Java, why should Java have a build tool written in Java? I have my own “build tool” written in C that is at least twice as fast as maven and yes it calls Javac. Part of it is XML, a really horrible config spec. But besides that we have all “adopted” Maven (and yet we all mostly hate it), I dont see any benefit to this tool. I would like it to go away. After that – lets get rid of eclipse and write an IDE in C that doesnt make me wait 2 seconds after every button push. Then being a “java” developer might stop sucking so much.


    April 26, 2013 at 12:09 am

    • :)

      I haven’t suffered from eclipse being slow but it sure uses a lot of memory :) Coding in Java will probably always suck a little because of the language and SDK legacy but there is no reason our buildtools should suck aswell.
      I agree speed is important for a buildtool and it’s obviously not a high priority for the maven developers (unless Maven 3 totally changed this, I still haven’t used it).

      Have you looked at NinjaBuild?


      April 26, 2013 at 4:33 pm

  9. I’m new to maven. I’m surprised that most users just have a single maven repository instead of a per-project repo. So if you one of your projects doesnt specify a version for a dependency, and another project upgrades that package, you have now changed the code in your unrelated first project- possibly without even realizing it!


    April 26, 2013 at 12:38 am

  10. Try to use maven with IntelliJ Idea it will appear in very different way imho.

    Milan Baran

    April 26, 2013 at 7:16 am

    • Hi Milan,

      I have used Maven from IntelliJ and the integration is(was?) better even if it was far from perfect. Also IntellJ’s buildprocess doesn’t suffer in the same way eclipse’s build process does.

      Please don’t misunderstand me, IntelliJ is a great piece of software and I do see how it is a nicer and tighter tool than eclipse in many aspects. There is however one aspect in which Eclipse is still unrivalled and that is kick ass background incremental compiling. It looks like IntelliJ also does this but intelliJ mostly reviews your code so that you know that it will compile when you compile it. In eclipse, once you save the file it is compiled and ready to go (for instance to run a unit test). This is priceless for a fast feedback junkie.
      The maven integration (when I last used it a year or so before wrote this post) broke this and turned eclipse in to a pretty average IDE compile wise.


      April 26, 2013 at 4:25 pm

  11. I 100% agree. Maybe it’s because I’m used to doing it all myself but trying to take away my control on the pretext of making it easier when in fact it’s actually making it more complex and hiding whats going on just worries me. Your black box comment is spot on.

    David Garratt

    February 6, 2018 at 7:58 pm

  12. It is a sad state of things indeed when things apparently remain the same eight years later. I guess this doesn’t change because the maven team doesn’t share my values on these things so maven will never be the tool for me.
    I just realized I haven’t used maven once since writing this post while (sadly) working with Java most of the time. Isn’t that a little bit surprising?


    February 7, 2018 at 7:14 pm

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: