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.

+35  A: 

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.

This may be somewhat true, but I've found that using Maven integration with Eclipse really helps trim the learning curve for folks.
Taylor Leese
@Taylor, I had a lot of problems with the plug-in, especially if you use some other version of Eclipse or heaven forbid RAD. I think it is getting there, however...
I've only used it with Eclipse 3.3, 3.4, and JBoss developer studio and agreed there are some minor annoyances (like the POM editor not playing nice) but I haven't had any major issues.
Taylor Leese
Its not the learning curve that bothers me. It's really not that hard to understand. My problem is that for large (commercial) projects, you get much less value than the effort spent. OK, your projects builds. Cool, but the cost of a man year spent, constant build failures due to external factors, 10 minute compiles instead of 5 seconds and an ugly eclipse workspace , it's just not worth it. Besides, for the same cost, you can more or less hire a guy that is constantly is building the trunk manually.
@Karlp - well, you don't understand it fully yet... 1.) "failures due to external factors" - you should create a project repository that you keep all your dependencies in, and that you control the versions of. 2.) "10 minute compiles instead of 5 seconds" - maybe for the initial maven install and first build - maven downloads all dependencies it needs plus your project - but regular builds you're doing to attempt to build your own code shouldn't be downloading - see 1 - also, offline mode. 3.) "ugly eclipse workspace" - maven works in all major IDEs (NB, IntelliJ) and from the command line.
sooo true.. love maven but that took 2 years to get over the steep learning curve (only have so much time to spend on the build system, so I worked in sort-but-much-longer-than-I-wanted iterations spaced by a loooong time inbetween)
+3  A: 

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.

"I wouldn't say it has a bad rep so much as it has a mixed rep" - I'd say that's probably more accurate, only negative opinions tend to stick out more.
I agree that porting a project to maven increases in difficulty experimentally relative to the project size (bigger project to import = harder import). using maven to start a project is the best approach to using maven. Else it might not be worth the effort.
+8  A: 

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.

I agree that initially people may miss the control they had with Ant, but once a project comes to accept the conventions that Maven imposes they will really see a gain in productivity from it.
Taylor Leese
Not true, Maven allows you to change the project structure, it just suggest a structure which is widely used.
I don't think this is true. Most of the complaints about Maven are about the ways in which it can fail, how slow it is or the documentation. I've never really noticed anybody complaining about the structure.
Dan Dyer
@Dan Dyer: I second that. The structure is actually one of few good things Maven does. It's everything else that makes Maven so horrible.
Carl Smotricz
+13  A: 

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

We should mass-produce it and sell it to all the villains for a huge profit!
Joachim Sauer
No! Maven cannot be used for profit. It can only be used for evil.
+1  A: 

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.

Ben Turner
You can set up a <dependencyManagement> section that declares the versions you want everything to use, no matter what they specify in their poms.As far as one component depending on differing versions of a subcomponents, that means the lib's developer knows it needs that version. If you just pile an arbitrary higher version in a lib (as with Ant), then you've just forced the issue, but in reality the libs still "want" varying versions.
Matthew McCullough
"speeds up development tenfold"? I hope that was hyperbole, and not exaggeration. It could not possibly be true.
Daniel Alexiuc
ok tenfold is an exaggeration :-) but i find that, if you play along nicely with the way maven wants to work, you can have a new project up and running very quickly.
Ben Turner
+1  A: 

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:

Ivy doesn't compete with Maven (maybe with Maven Ant Tasks, but not with Maven).
Pascal Thivent
Ivy doesn't compete with Maven Ant Tasks, it competes with Maven dependency management.
Damien B
+1  A: 

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.

+2  A: 

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

Ivy's a non-starter. It doesn't publish artifacts in a standard way that is easily consumed by other tools. There's a reason why Ivy reads pom.xml files to gain dependency metadata from the repo.... Maven set the standard.
+90  A: 

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.

Kevin Peterson
To those who understand Maven, no explanation is necessary. To those who don't, no explanation is possible.
One of your bullet points is false. -o - offline mode, so no, it does not make your build process dependent on your network connection.
I agree on the all-or-nothing point. I've seen to many people waste too much time trying to keep half of their project portfolio in ant and half in maven. Once you commit, you have to put the work in to convert every part of your deployment.
@MetroidExcept at that point you may as well not be using Maven. Which in turn answers the question ;)
@Apocalisp: So, in other words, the only people who understand Maven are the people who wrote it?
R. Bemrose
@Apocalips : Good one :), @Bemrose : No, is just a matter of accepting that nothing is perfect, stop complaining and start using it
It astounded me as well that Better Builds With Maven doesn't say what Maven is. I have two hypotheses. a) They don't know what it is. b) There is no such thing. I'm leaning towards b.
Why is it all-or-nothing when you quite easily call ant targets and thus mix the two? I don't see the problem.
*Maven is all-or-nothing.*This isn't true. You can use maven for dependency management and nothing else if you want. All it takes is one working example of how to use the Maven ant tasks to read your pom file and generate an ANT classpath containing all your dependencies.
Just found this topic again after a year. @adrian tarau: No, I'm pointing out that Apocalisp's logic is crazy moon logic. If you didn't write Maven, then to start you don't understand it. By his definition, no one will be able to explain it to you, so you never will understand it.
R. Bemrose
*Maven makes your build process dependent on your network connection.* pretty blatently not true. If you need to download dependencies you don't already have, then yes you need a network connection. How is that not true of any other build tool?
matt b
Hey, slag off, I ghost wrote that section. I stand by it. I'd much rather work somewhere that uses Maven vs. somewhere that doesn't. Not using Maven at this point is a marker for working with architect astronauts.
+3  A: 

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.
I think Maven users would be better serves by having the IDEs allow for importing missing or 3rd party jars into the local repositories. How hard would it be to have a "pick the jar click import" dialog box?
@sal My guess is that Maven doesn't want to promote a practice that breaks portability.
Pascal Thivent
I consider the fact that it's hard to add jars from random places to be a strength. If you're in a team environment, and you need to use an odd jar, you should be deploying that jar to your team's maven repo. That way, the rest of the team and your CI servers will be performing the same build.Everybody runs the same build is a foundation of the maven philosophy.
+46  A: 

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

What I *really* would want, is to have a big nice green button in eclipse, that says: Add this branch of th workspace/workingset/metaproject to the build server, that runs a continous build cycle. And maybe also a dependency resolver, that can resolve and keep track of external dependencies.
I agree with some of what you say actually, though I think I finally got it right. To get what you want however you can have a look at Ivy, did not try it yet but it seems to bring dependency management in a more structured Ant environment.
So, did you find any good alternative to Maven?
No. Current project uses Ivy, and while it keeps my blood pressure within tolerable limits, its far from the big helpful green button in my vision...
"The Eclipse integration is awful." Not true, if you use the m2eclipse plugin:, yes I agree that it's painful. But the plugin eliminates the need for getting dependencies and building the project outside of Eclipse (among many other killer features).
The Eclipse integration is *still* awful. In spite of having up-to-date plugins, there are plugin-controlled maven tasks that fail with obscure error messages. Colleagues then tell me to drop to a command shell and run the same command... then it mysteriously works.Eclipse is a mature environment, the maven plugin lags far behind.
Carl Smotricz
There is a fundamental difference how Maven and Eclipse defines what a project is. In Maven, a project is more or less a convenient way of organizing the source code. Eclipse was initially designed so that you were able to work on one or a few more or less unrelated projects at the same time. Later (not always sound) requirements lead to IBMs abuse of projects as "modules" which eclipse actually handles rather bad. In order to converge the definitions, in a lot of cases, maven projects should probably be mapped to eclipse source folders. However, as maven is teh suck, why bother.
Hey! I bemoan the fact that the next time I will be a prime age is 29, and the next perfect cube age is 64, and my last perfect penteract age will be 32... but I don't actively advocate maven.
Christopher W. Allen-Poole
+67  A: 
  • 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.
++ It makes hard things easy, and simple things hard.It's so right!
Martin K.
"It promises much but betrays you like a beautiful and seductive but emotionally cold and manipulative lover."hahahaha... that sounds alot like that master fong from "Balls of Fury"
Re bullet point 2: It uses elements almost always, attributes almost never, so the XML is even harder to read than Ant's!
Carl Smotricz
+1 for the last bullet. Nothing makes my day like coming across an awesome and hilarious analogy that is so true.
The documentation is not poor, it is excellent.
+12  A: 

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.

+52  A: 

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.

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

Dominic Mitchell
I don't particularly mind the XML format (Eclipse can look after most of the tedious parts) and build instructions for large projects are typically nasty and complex anyway. For example, you've not truly bashed your head out on a brick wall until you've tried to get GNU automake to do something it doesn't care for…
Donal Fellows
+12  A: 

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%

+10  A: 

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.

Steve B.
+5  A: 

Too much magic.

Adam Jaskiewicz
Be more specific - what is so magical about it that isn't documented?
It's magical as soon as you have to search the web during 2 hours to find out why something doesn't work as expected. If you want a specific exemple: why is my plugin not executed? You have 2 hours.
Damien B
+1  A: 

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.

+5  A: 

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.

Zac Thompson
+4  A: 

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.
Robert Munteanu
+1 for linking to an alternate repository implementation.
Donal Fellows

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 )

+5  A: 

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.



I agree that the idea is better than the execution. It's not a small task they picked to their defense, but I regularly wonder whether things couldn't have been done in a more straightforward fashion.
+12  A: 


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



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

Sasha O
Ant doesn't compete with Maven. Ivy doesn't compete with Maven (it competes with Maven Ant tasks). Maven is more than a build tool + dependency management. Period.
Pascal Thivent
+9  A: 

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.

I agree with this. I think the value of the dependency-management is overstated. Sure it's neat when it all works but it introduces several potential failure points (not to mention potential security holes). You can setup your own repository server to mitigate the problems somewhat, and lock-down the version numbers to avoid unexpected updates, but I still prefer just adding the dependencies to version control since they don't change that often and it guarantees a repeatable build.
Dan Dyer
+2  A: 

To me, there are as many pros as there are cons to using maven vs ant for in-house projects. For open source projects however, I think Maven has had a great impact in making many projects much easier to build. It wasn't too long ago that it took hours get the average OSS Java (ant based) project to compile, having to set a ton of variables, downloading dependent projects, etc.

You can do anything with Maven you can do with Ant, but where Ant doesn't encourage any standards, Maven strongly suggests you to follow it's structure, or it'll be more work. True, some things are a pain to set up with Maven that would be easy to do with Ant, but the end result is almost always something that is easier to build from the perspective of people who just want to check out a project and go.

+9  A: 

I'd like to counter a few of the complaints made in this forum:

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.

This isn't true. Maven's big win is using it to manage your dependencies in a rational way and if you want to do that in maven and do everything else in ant, you can. Here's how:

<?xml version="1.0" encoding="UTF-8"?>
<project name="foo" basedir="." xmlns:maven="antlib:org.apache.maven.artifact.ant" >
  <maven:dependencies verbose="true" pathId="maven.classpath">
    <maven:pom id="maven.pom" file="pom.xml" />

You now have a classpath object named 'maven.classpath' which contains all the maven dependencies defined in the pom file. All you need is to put the maven ant tasks jar in your ant's lib directory.

Maven makes your build process dependent on your network connection.

The default dependency and plugin fetching process depends on a network connection, yes, but only for the initial build (or if you change the dependencies or plugins in use). After that all the jars are locally cached. And if you want to force no-network connection, you can tell maven to use offline mode.

It imposes rigid structure on you from the start.

Its not clear if this is referring to the file format or the 'convention versus configuration' issue. For the latter, there are a lot of invisible defaults like the expected location of java source files and resources, or the compatibility of the source. But this isn't rigidity, its putting in sensible defaults for you so you don't have to define them explicitly. All the settings can be overridden pretty easily (though for a beginner it can be hard to find in the documentation how to change certain things).

If you're talking about the file format, well that's covered in the response to the next part...

It's XML-based so it's as hard to read as ANT was.

First off, I don't see how you can complain that some aspect of something 'Isn't better than ant' as a justification for it having a bad rep. Second, while it still XML, the format of the XML is much more defined. Further, because its so defined, its a lot easier to make a sensible thick client editor for a POM. I've seen pages long ant build scripts that jump all over the place. Any ant build script editor isn't going to make that any more palatable, just another long list of interconnected tasks presented in a slightly different way.

Having said that there are a few complaints that I've seen here that have or had some vailidity, the biggest being

  • Documentation is poor/missing
  • Reproducible builds
  • Eclipse integration is bad
  • Bugs

To which my response is twofold. First, Maven is a much younger tool than Ant or Make, so you have to expect that its going to take time to get to the maturity level of those applications. Second is, well if you don't like it, fix it. Its an open source project and using it and then complaining about something that anyone can have a hand in solving seems fairly asinine to me. Don't like the documentation? Contribute to it to make it clearer, more complete or more accessible to a beginner.

Reproducible builds problem breaks down into two issues, version ranges and automatic maven plugin updates. For the plugin upates, well unless you're making sure when you rebuild a project a year later that you're using the exact same JDK and exact same Ant version, well this is just the same problem with a different name. For version ranges, I recommend working on a plugin that will produce a temporary pom with locked versions for all direct and transitive dependencies and make it part of the maven release lifecycle. That way your release build poms are always exact descriptions of all the dependencies.

+3  A: 

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.

Big +1, great answer.
Pascal Thivent
@Pascal. In case problems with Maven there is a stackoverflow and you here :)
+3  A: 

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

Pascal Thivent
+1  A: 

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!!!"

Wow, that's really funny. You are a funny guy. You had me just on the floor there with the "complex collection of popsicle sticks" line.Maybe you haven't seen some of the Ant builds I've seen lately, which can be characterized by the phrase: "Spaghetti code build created by some alpha developer too smart to write a lick of documentation".
+3  A: 

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.

Carl Smotricz
I've never had Maven pull the latest off of a dependency unless I was using a SNAPSHOT dependency or added a new feature that required something. If I ask for version 1.2.3, and I have 1.2.3 in my local repository, I don't get 1.2.3 again.
Mike Cornell
You control your direct dependencies, yes. Who controls your dependencies' dependencies?
Carl Smotricz
For you're first point, about attributes, that is supposed to be addressed in the forthcoming, (for like a LONG time now I'll admit) Maven 3.
@mezmo: That would be highly welcome. Thanks for the info!
Carl Smotricz
+1  A: 

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.

Mike Cornell
+1  A: 

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?

+1  A: 

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

Alex Worden
+2  A: 

I like maven. I've used it since pre 1.0. It's a powerful tool that on balance has saved me considerable amounts of time, and improved my development infrastructure. But I can understand the frustration some people have. I see 3 types of frustration:

  1. where the causes are real concerns (e.g. verbose POMs, lacking documentation),
  2. some is misinformation (e.g. "you have to have an internet connection to build" - not true - doin't, this can be avoided),
  3. some of it is vented at maven but really someone else is culpable ("don't shoot the messenger").

For the first case, real problems - well, sure, there are problems, POMs are verbose, documentation could be better. Yet despite this, it is possible to get good results with maven in quick time. I cringe every time I get a project built with ant, and try to import this into my IDE. It can take a long time to set up the directory structure. with maven, it's just a case of opening the POM file in the IDE.

For the second case, Maven is complex, and misunderstandings are commonplace. If maven 3 can find a way to address this complexity (or even perceived complexity) that would be good. maven does take a considerable investment, but, in my experience, the investment pays for itself quickly.

For the last point, I think the gripe about maven's transitive dependencies is probably the best known example.

Transitive dependencies are the nature of real software employing reuse. Windows DLLs, Debian packages, java packages, OSGi bundles, even C++ header file includes all have dependencies and suffer the dependency problem. If you have two dependences, and each uses a different version of the same thing, then you have to try to resolve that somehow. Maven doesn't try to solve the dependency problem, but rather brings it to the forefront, and provides tools to help manage the problem, such as by reporting conflicts and providing consistent dependencies for a hierarchy of projects, and in fact provides absolute control over a project's dependencies.

The approach of manually including dependencies with each project (one poster says he checks all dependencies into source control) is runing the risk of using the wrong dependency, such as overlooked updates when a library is updated without checking in updates for it's dependencies. For a project of any size, managing dependencies manually is surely going to lead to errors. With maven, you can update the library version you use and the correct dependencies are included. For change management, you can compare the old set of dependencies (for your project as a whole) with the new set, and any changes can be carefully scrutinized, tested etc.

Maven isn't the cause of the dependency problem, but makes it more visible. In tackling dependency issues, maven makes any dependency "tweaks" explicit (a change to your POM overriding the dependency), rather than implicit, as is the case with manually managed jars in version control, where the jars are simply present, with nothing to support weather they are the correct dependency or not.


Well I've been wasting 2 days now with maven. Using m2eclipse, I found that the dependencies reported in eclipse are missing from the repositories, just like that. When I tried IAM and wanted to generate a simple blank project for struts 2, I found that v2.0.9 had also been deleted from the repository. When I finally manually added the artifacts and stuff, the project created itself only to find out that whatever I ask IAM to do, it responds with: no maven 2 projects found..... Hey, didn't I just use the Maven 2 project wizard??? Maven has been a pain in my ass since day one. THe idea behind it is very nice. In practical terms however, it lacks discipline from all parties involved. And that makes it virtually worthless. BEcause today your project might build. ANd tomorrow, when some dumbass deleted some pom from some repo, you are screwed. As simple as that. It is NOT usable for professional enterprise develoment! Not at all. Maybe in a year or 5?


The short answer: I've found it very difficult to maintain a Maven build system, and I would like to switch to Gradle as soon as I can.

I've been working with Maven for over four years. I would call myself an expert on build systems because in the last (at least) five companies I've been in, I've done major renovations on the build/deploy infrastructure.

Some of the lessons I've learned:

  • Most developers tend not to spend a lot of time thinking about build systems; as a result, the build turns into a spaghetti mess of hacks, but they do appreciate it when that mess is cleaned up and rationalized.
  • In dealing with complexity, I would rather have a transparent system that exposes the complexity (like Ant) than one that tries to make complex things simple by imposing rigid restrictions, like Maven. Think of Linux vs. Windows.
  • Maven has a lot of holes in functionality which require byzantine workarounds. This leads to POM files that are incomprehensible and unmaintainable.
  • Ant is super-flexible and understandable, but Ant files can get pretty big too, because it's so low-level.
  • For any significant project, developers have to create their own build/deploy structure beyond what the tool provides; the suitability of the structure to the project has a lot to do with how easy it is to maintain. The best tools will support you in creating a structure and not fight you.

I've looked into Gradle a bit and it looks like it has the potential to be the best of both worlds, allowing a mix of declarative and procedural build description.


Maven does not easily support non-standard operations. The number of useful plugins is though constantly growing. Neither Maven, nor Ant easily/intrinsically support the file dependency concept of Make.


Maven does not respect the KISS principle. Try to do anything besides mvn clean install and you are in trouble. With ant you can do whatever you want without any pain.

Sergio Oliveira Jr.
+2  A: 

I believe that Maven has a bad rep because most detractors have not observed the combination of Maven + Hudson + Sonar. If they had, they would be asking "how do I get started"?

Zac Thompson
+1 for mentioning Sonar.
Donal Fellows