Why does Maven have such a bad rep?

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.

• 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.

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.

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 :-)

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.

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

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%

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.

Cons:

• 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 (http://www.sonatype.com/products/maven/documentation/book-defguide), 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 (http://maven.apache.org/plugins/maven-antrun-plugin/) orexternal programs. My personal favorite is Groovy plugun (http://groovy.codehaus.org/GMaven).

Competition:

• 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.

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.

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.

It deserves the reputation it has got. Not everyone needs the rigid structure that Maven's developers thought is appropriate for every single project. It is so inflexible. And what is 'Pro' for many people, the dependency management, is IMHO its biggest 'con'. I am absolutely not comfortable with maven downloading the jars from the network and lose my sleep over incompatibilities (yea, the offline mode exists, but then why should I have all those hundreds of xml files and checksums). I decide which libraries I use and many projects have serious concerns about builds dependant on network connection.

Further worse, when things do not work, you are absolutely lost. The documentation sucks, the community is clueless.

A year later I wanted to update this: I no longer have this opinion about the Maven community. I would not write this answer if the question were asked today. I'm going to add my current opinion as a separate answer.

This is a very subjective answer, but the question is about opinions, so ...

I like Maven, and am liking it better the more I get to know it. One thing affecting my feelings about it, however: the maven community is largely centered around Sonatype ("the maven company", it's where many of the Maven honchos are working), and Sonatype is pushing its corporate products pretty aggressively on the community.

An example: The "Maven Book" twitter stream links to a supposed introduction to repository management.

Sorry, but that "intro" is half-information, half sales pitch for Nexus. Pop quiz: are there any other repo managers besides Nexus and Nexus Pro? Also, what does that have to do with the supposedly open-sourced Maven Book? Oh, right, the chapter on repository management has been spun off into a separate book ... about Nexus. Huh. If I contribute to the Maven book, do I get a referral fee if I cause an increase in Nexus sales?

Imagine if you were participating in a Java development forum and it was clear that the Sun employees discussing Java were going to seize every possible opportunity to talk about NetBeans and "NetBeans Pro". After a while, it loses some of its community feeling. I never had an experience like that with Ant.

Having said all of that, I do think that Maven is a very interesting and useful system (I'm not calling it a tool, like Ant is, Maven is broader than that) for software development configuration and build management. The dependency management is a blessing and a curse at times, but it's refreshing -- and certainly not the only advantage Maven offers. I'm probably reacting a bit too strongly to the Sonatype shilling, but it hurts Maven by association, in my opinion. I don't know if this opinion is shared by anyone else.

I think Maven gets a bad rap because it imposes structure on your project, whereas other tools such as Ant allow you to completely define the structure any way you wish. Agreed also that the documentation is bad, but I think primarily the bad rap that Maven gets is because people are so used to Ant.

Too much magic.

Because unsatisfied people do complain while satisfied people don't say they are satisfied. My point is that there are far more satisfied maven users than unsatisfied but the later make more noise. This is a common pattern from real life too actually (ISP, phone carrier, transports, etc, etc).

The single most important issue to me is that Maven, when not configured properly, may not produce repeatable builds, due to:

• unreliable remote repositories;
• dependencies on plugins and libraries with either SNAPSHOT versions or no versions.

Contrast this with an ant build which - although verbose and tiresome IMO - works since all jars are checked in locally.

The good part is that the problems are addressable:

• use your own maven repository, which has become dead simple, I'm using Archiva with good results;
• always properly version your dependencies. Maven has started locking down plugin versions in the super-POM starting with 2.0.8 or 2.0.9 and all your dependencies should be on released versions.

great idea - poor implementation.

I moved a project from Ant to Maven recently. It worked well at the end, but I had to use two different versions of maven-assembly-plugin and maven-jar-plugin in the same pom (got two profiles) because what worked in one version was broken in another.

So it was quite a headache. Documentation isn't always great but I must admit that it was relatively easy to google answers.

make sure you always specify versions of plugings you use. Don't expect that new version will be backwards compatible.

I think controversy comes from the fact that maven still evolves and the process is painful sometimes.

regards

v.

Some of my pet peeves with Maven:

• The XML definition is super clumsy and verbose. Have they never heard of attributes?

• In its default configuration, it always scours the 'net on every operation. Regardless of whether this is useful for anything, it looks extremely silly to need Internet access for "clean".

• Again in the default, if I'm not careful to specify exact version numbers, it will pull the very latest updates off the 'net, regardless of whether these newest versions introduce dependency errors. In other words, you're placed at the mercy of other peoples' dependency management.

• The solution to all this network access is to turn it off by adding the -o option. But you have to remember to turn it off if you really want to do dependency updating!

• Another solution is to install your own "source control" server for dependencies. Surprise: Most projects already have source control, only that works with no additional setup!

• Maven builds are incredibly slow. Fiddling with network updates alleviates this, but Maven builds are still slow. And horribly verbose.

• The Maven plugin (M2Eclipse) integrates most poorly with Eclipse. Eclipse integrates reasonably smoothly with version control software and with Ant. Maven integration is very clunky and ugly by comparison. Did I mention slow?

• Maven continues to be buggy. Error messages are unhelpful. Too many developers are suffering from this.

Good question. I've just started a large project at work and part of previous projects was to introduce modularity to our code-base.

I've heard bad things about maven. In fact, it's all I've ever heard about it. I looked at introducing it to solve the dependency nightmare we're currently experiencing. The problem I've seen with Maven is that it is quite rigid in its structure, i.e. you need to conform to its project layout for it to work for you.

I know what most people will say - you don't have to conform to the structure. Indeed that's true but you won't know this until you're over the initial learning curve at which point you've invested too much time to go and throw it all away.

Ant is used a lot these days, and I love it. Taking that into account I stumbled across a little known dependency manager called Apache Ivy. Ivy integrates into Ant very well and it's quick and easy to get basic JAR retrieval setup and working. Another benefit of Ivy is that it's very powerful yet quite transparent; you can transfer builds using mechanisms such as scp or ssh quite easily; 'chain' dependency retrieval over filesystems or remote repositories (Maven repo compatibility is one of its popular features).

That all said, I found it very frustrating to use in the end - the documentation is aplenty, but it's written in bad English which can add to frustration when debugging or attempting to work out what's gone wrong.

I'm going to revisit Apache Ivy at some point during this project and I hope to get it working properly. One thing it did do was allow us as a team to work out what libraries we're dependent on and get a documented list.

Ultimately I think it all comes down to how you work as an individual/team and what you need to resolve your dependency issues.

You might find the following resources relating to Ivy useful:

• Apache Ivy vs Maven 2 comparison
• Apache Ivy FAQ
• Apache Ivy feature list

I love Maven - it boosts productivity, and I am very happy that I am no longer using Ant (phew!)

But if I could change things it would be:

1. Make pom.xml file less verbose
2. Make it easier to include .jars not from the repository.

There are lot of reasons why people don't like Maven, but let face it they are very subjective. Maven today with some good (and free) books, better documentation, biger set of plugins and lot of referential succesful project builds isn't the same Maven as it was one or two years ago.

Using Maven in simple projects is very easy, with bigger/complicated ones there is need for more knowledge and deeper understanding of Maven philosophy - maybe in company level a position for Maven guru like network admin. Main source of Maven hates statments are often ignorance.

Another niggle for Maven is lack of flexibility like e.g. in Ant. But remeber Maven has set of conventions - sticking to them seems to be hard in the begining, but in the end often save as from problems.

Current success of Maven proves its value. Of course nobody is perfect and Maven has some cons and its quirks but in my opinion Maven slowly sways his opponents.

I wouldn't say it has a bad rep so much as it has a mixed rep. If your project follows the "convention over configuration" paradigm advocated by Maven then you can get a lot leverage out of it. If your project doesn't fit well into Maven's world view then it can become a burden.

To that end, if you have control over the project, then Maven may be the way to go. But if you don't and the layout is determined by someone not a fan of Maven, it may be more trouble than it's worth. The happiest Maven projects are probably the ones that started as Maven projects.

If you're going to bet your business or job on a development project, you want to be in control of the foundations - i.e. the build system. With Maven, you are not in control. It is declarative and opaque. The maven-framework developers have no idea how to build a transparent or intuitive system and this is clear from the log output and the documentation.

The dependency management is very tempting since it could same you some time at project inception but be warned, it is fundamentally broken and will eventually cause you a lot of headaches. When two dependencies have incompatible transient dependencies you will be blocked by a rat's nest of complexity that will break the build for your entire team and block development for days. The build process with Maven is also notoriously inconsistent for different developers in your team due to inconsistent states of their local repositories. Depending on when a developer created their environment, or what other projects they're working on, they will have different results. You'll find that you're deleting your entire local repository and having Maven re-download jars far more often than the first time setup for a dev branch. I believe OSGI is an initiative that is attempting to fix this fundamental problem. I would say that perhaps if something needs to be so complex, the fundamental premise is wrong.

I've been a maven user/victim for over 5 years now and I have to say that it will save you far more time to just check your dependencies into your source repository and write nice and simple ant tasks. With ant, you know EXACTLY what your build system is doing.

I've experienced many, many lost man weeks of time at several different companies due to Maven problems.

I've recently tried to bring an old GWT/Maven/Eclipse project back to life and 2 weeks of all my spare time later, I still can't get it to build consistently. It's time to cut my losses and develop using ant / eclipse me thinks...

I think one major reason for the bad reputation is that maven2 solves several complex problems (build automation, dependencies, managing repositories) as a one shot solution. Therefore you have to face these tough problems while starting to use maven. So it is a kind of "kill the messenger"-effect.

Other approaches (e.g. ant+ivy) often do not give you the chance to blame one single tool for all the problems you encounter. It is more like "okay ant not really easy to get started, ivy has some issues. But at least we don't have to wrestle with maven!" Saying that one does not recognize that all these problems taken together do not differ too much from the issues you encounter when using maven. It just may be a litte bit easier to tackle one at a time. BTW, I set up a build system based on ant+ivy in the past months. And I am really glad I did not have to use maven2 ;-)

I'd distinguish between Maven 1 and 2: the former has a (deservedly) bad reputation; the latter is an improvement and a rising "standard".

My personal opinion is that Maven 2 is more complex and rigid than I like. One man's standard is another's straight jacket. I agree with the "too much magic" comment above. When I compare the simplicity of Ant to the complexity of Maven 2, I know which one I prefer.

I'll admit that I know Ant far better. I'm in the process of groking Maven 2, but I'm not all the way there yet. My poor opinion might say more about me and the state of my knowledge than it does about Maven 2's true worth.

Maven is a software management tool that can boost your productivity. I believe that such a tool is essential for software development in a new era.

However, Maven isn't appropriate for all code bases. If you need to support a large legacy code page, or you import code from a third party, then it would be better to avoid using. Maven expects things to be in a certain way (convention over configuration). If you are starting a new project, then this is more than fine. If, however, you have a full system you need to support, the lack of flexibility is a nightmare.

Another reason that people usually complain about maven is the steep learning curve. Also IDE integration is still not very mature. Apache is offering two plug-ins for Eclipse. The one is "mature", the other one offers a new approach. I suppose the new wouldn't be needed if the first one was adequate.

Another, more serious complain about Maven, is the use of XML for doing programming job. Perhaps tools like Buildr are the way to go.

It's common for Maven defenders to say "well, you just don't understand it". This, they think, is a real snappy rejoinder.

It goes like this:

Super Programmer: "hey, I need to keep this door open, does anyone have a doorstop" Maven Programmer: "why yes, here's one" (shows him a complex collection of popsicle sticks) Super Programmer: "these sticks aren't holding the door open!" Maven Programmer (smug, chuckling): "You just don't understand it. I suggest you read the manual, and really study the thing for about 1 year!!!"

The biggest reason Maven has a bad rap is IDE integration. Yes, I know about m2eclipse. I like m2eclipse. I like Netbeans' integration even more.

Here's the problem. Some larger shops built tools to force Maven to work with things like RAD 7.0. It doesn't work well. These hackarounds exist to try to get Maven to behave inside of a tool they are not allowed to change (RAD 7.0). In my case the hackarounded maven builds only work inside Netbeans. Eclipse 3.5 with m2eclipse chokes something horrible.

Most of the devs here hate Maven. They don't hate Maven. They've never really used Maven.

It's disappointing, but it's not really Maven's fault. Maven worked more than fine for me in another life. Here, it's debilitating because of the IDE and the tools meant to make it usable fail to do so.

Okay I DON'T know much about Maven to go in finer details, but I have tried to make it work more times than I care to admit.
For me to use Maven is quite simple provided:
.You need to "hire" a special Maven guru which you don't for ant; otherwise ask your developers to spend time learning how to "build" their work instead of leaning how to "do" their work
.You need to "buy" the Book "they" sell if you want to really understant it.

And then:
.It basically solves only one real problem "dependencies" I wonder how many projects are out there who depend on so many many many other projects that they need a special tool to solve dependencies for them? And ANT can't do it?
. I personally don't upgrade to newer versions of open source frameworks blindly without seeing the need to do so. If it is working then don't fix it, right?

But then this is subjective is right?

We use maven2 in all our projects and it speeds up development tenfold (combined with a nice continuous integration platform).

The only feature of maven2 that has caused us a lot of headaches in the past is the transitive dependency mechanism. In a Utopian world it would be the end-all solution to all dependency issues but in practice it tends to send you straight to dependency hell.

Our main problem came from the fact that various components in the default maven2 repository depend on different versions of the same library (i.e component1 and component2 both require a logging framework but component1 requires v1 and component2 requires v2).

To solve this we simply have our own local repository containing all the libraries we need. This allows us to ensure that all libraries we use that have their own dependencies depend on the same versions of other libraries.

The already mentioned "all-or-nothing" approach was the reason I'm usually using Ant instead ... Far more often you get to work on a "legacy" project, that already has a defined structure that you can't change just because Maven wants things otherwise.

Ant on the other hand can be used anytime, no matter the projects disorganization.

Regarding the alternatives, I've read good things about rake.

( Btw, I'm talking about Maven 1, haven't yet looked into Maven 2 )