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.

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

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

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.

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

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.

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

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.

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

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

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.

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.

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%

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.

Too much magic.

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.

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.

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.

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 )

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.

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.

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.

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.

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" />
</maven:dependencies>
</project>

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.

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.

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

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

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.

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?

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

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

Maven does solve working problems, it builds java softwares, and easy dependence management. But it is very different from Ant, and GNU Make, or other Unix-like package management system. This make new-comer have to pay a lot to learn it.

There are lots Maven document, but some of them pushing you away, like this from "using m2eclipse":

By simply entering a groupId into the query field, m2eclipse queries the repository indexes and even shows a version of the artifact that is currently in my local Maven repository. This option is preferred because it is such a tremendous time saver.

I really hate to figure out a long sentence and found it says nothing. I can remember how good feel when reading python official tutorial, and erlang's. Good document will show the author has good senses.

Maven appears strange to newcomers, it's command line style is different from Unix command line traditions. If you pay time to go through "maven by examples" or "The Definitive Guide", it pay off, you can find it on http://www.sonatype.com/. But even if you read all those documents, and can use the tool with confidences, you can come across troubles time by time, some caused by software bugs. And expert get ways to live with it and keep productive.

After all, Maven is open source software, it contributes knowledges to freelance engineers. And this make it respectful. When people talks more about it's bad reputation, it is doing good job for open source world.

So, as how skilled people use any tools, just use it, and don't depend on it, depend on yourself.

It's more complicated than the language you used to write your project. Getting it configured right is harder than actual programming.

My take here, based on the pitfalls of convention over configuration:

http://chriswongdevblog.blogspot.com/2011/01/trouble-with-being-conventional.html

My issue with Maven is the difficulty in discovery and limitless complexity. That, and watching colleagues waste half a work day day fighting Maven build issues. Also IMHO, the Maven integration with Eclipse makes things worse, because you have multiplied the number of places where things go wrong.

I've struggled my way through most/all the negatives mentioned here, and similar objections from teammates, and agree with them all. But I've stuck it out and will continue to do so by holding firm to the one objective that only maven (or gradle perhaps) really delivers on.

If you're optimizing for peers (open source developers), ant/make/whatever will do. If you're delivering functionality to non-peers (users), only maven/gradle/etc will do.

Only maven lets you release a small bundle of source code + poms (no embedded lib/binary dependency jars with cryptic names and no dependency info) with a well documented standard project layout that can be loaded by any IDE by someone that hasn't absorbed the developers' idiosyncratic layout conventions. And there's a one-button install procedure (mvn install) that builds everything while acquiring any missing dependencies.

The result is an easy on-ramp those users can follow to find their way into the code, where the poms can point them to relevant documentation.

Apart from that (indispensible) requirement, I dislike maven as much as anyone.

My answer: most users complains about maven because they were looking for its pros, but don't have time (or they don't want endure) in setting up their "company environment". That's a personal choice, it can depend from personal patience, the job environment(bosses never understand that a well done thing waste less time than an eternal bugfix cycle), etc..

However, In the following cases you can have only maven on your workstation without getting mad:

1. a simple library with some beans.
2. a simple "all-in-one" war.
3. even a multi-module project, that has the "standard" dependencies (spring, hibernate,apache stuffs and whatever you can find in the central repository) but DOESN'T HAVE any dependencies on YOUR libraries.

The problems starts to come when you want more, like create your wrappers to standard frameworks classes, or reusable component libraries, you always want to use a set of plugins you like, etc..

In that case you have to invest your time in learning: I read in previous posts that someone talk about wasting half day or 2 days...that is not enough, at all: we are talking about modify your poms continuously for at least 1 month.

If you wanna use maven in complex projects, you should in order:

1. have your internal repository: it's not an option, it's mandatory. I tried Artifactory and Nexus, they can create troubles at the beginning but when you setup them once, you forget them.
2. create a "master pom" containing all the plugins (with relative version specified) you need, but you must avoid to put there your standard dependencies if you don't wanna get in trouble (for that, see the scope=import in dependenciesManagement ). this is the hardest part, but you can start copying a master pom of a famous project (spring, tapestry, ecc...) and strip what you don't need.
3. if you have a complex project, you must think at what you want before you start to create the artifacts. For example, in a project that has a (war + WebServices Client) + (Webservice Server + spring + hibernate + Jbpm + whateverelse....) it's a good idea to create an "api" module that is referred by both the client and the server, but that contains only model+interfaces and does't bring the "server side" dependencies in the client side and the opposite. Fail in that, and maven will become a living hell on earth.
4. if you use Eclipse, m2e plugin is essential: ok, it can be slow, sometimes you should refresh the project and update the project configuration, etc... but finding the "project build path" already setted up is worth of everything. And in the worst case, the command line will always works.
5. While a Continuous Integration server is optional, it's strongly recomended at least for your common libraries. Putting a web application on CI can be too much(you don't reuse a webapp on several projects), but putting on CI your standard base classes, your "always used" entity beans, etc.. is priceless. Remember that these components are not used only by you, but they can be used even by your team mates while you are busy on other parts of code and that you can forget (i often do) to deploy manually in the company repository to make them available to the team members.

To have all these setted up... well, you can even spend months at the beginning, but once you get used to that, you will speed up a lot your development.

Personally I didn't use Gradle yet, I don't know if it's better or worst than Maven.

Any Java developer can easily become an expert ANT user, but not even an expert Java developer can't become a beginner level MAVEN user.

Maven will make your developers scared s***less for doing anything related to Build and Deployment.

They will start respecting Maven more than the War file or Ear file!! which is bad bad bad!

Then you will be left at the mercy of online forums, where fan-boys will berate you for not doing things the "Maven way".

Very simply, Maven wants to own the world. It wants to define projects, how they're laid out on the file system, where the jars go in its cutesy local cache, how to fetch things, dependency graphs, build plugins, ide plugins, etc etc etc.

Some people love that kind of thing, admire it. For me, it's all about the quality, I could care less about your boooooring theories. Just execute, do it flawlessly, and then preferably fade into the background until I decide to mess with you again.

My message to Sonatype and Maven adherents/apologists is that you do not yet ooze with quality. pom.xml format is too verbose, academic, and tedious - fix it. Complex, multiproject builds are maddening to setup with Maven - why so hard? Fine tuning when to fetch and when not to fetch underspecified jars would be an interesting thing - until we get that, the maven strategery of fetching whenever we can/think we want to is maddening. SNAPSHOT is always all in caps because it's screaming/laughing at me and driving me mad? The minutae and goofy/unique ways cruddy open source maven plugins plug into poms is maddening. Classpath issues with no good way to resolve them? Oh yeah, and the legacy apache commons-* groupId's polluting my repository root are maddening in a "the cheese triangles don't go that way!!"-rage sort of way. m2eclipse is pure concentrated madness, die monster die, kill it with fire it's the only way we can be sure.

Maven embarrassed me once to a client - it's inexcusable that a tool so got in the way of my being productive! I want my tools (and their makers) to act like the humble servants they are. When I ask Maven who the king is, I expect the answer to be "DAVE" followed by pleasantries and much bowing and lowing! :)

Inertia is the real story with Maven. If you want to play with open source java, you're pretty much going to be pulling from a Maven repository. So, if you want to play nice there, you had better be able to get your dependencies the Maven way and learn to read poms... Thank goodness for Ivy and IvyDE, that I can set my maven dependencies in both Ant and Eclipse and not be stuck with the Maven toolchain.

Maven repository server software I've used like Nexus and Artifactory are neat, futuristic tools. They are glittering jewels compared to the rest of the maven ecosystem.

My Maven experience feels like how Eclipse felt back in the day. Eclipse wanted to own the world too with their dumb ideas, and it took a long time for the platform to mature, years and years, before I really allowed Eclipse to own my world. Perhaps in years and years Maven can reach that level of quality? At this point, I say "never again shall mine eyes witness the horrors", but I was saying that about Eclipse 1.0 too when it came out. :)

Maven is cool.

Stop listening to the alternatives, because right now, there aren't any - which aren't just toys.

Apart from the Microsoft development toolchain - it's best technology that money can't buy.

All these groups who are trying to push 'toolchain du jour' - it's just a cheap attempt to sow confusion and grab market-share.

Haters be hating.

• SBT

Greatest misnomer in history of the earth. Can your Build pass a Turing test? Fucking ridiculous, a step 10 years back in time with it's ridiculous DSL. Uses IVY dependency management, Maven's middle sibling.

• ANT

Great for that first project after you graduate from Shockwave development.

You understand XML, and are enthusiastic, but don't really understand build phases, restarting a project 6 months later, why Version Controlling binary artifacts is a false panacea or that someone other than oneself will one day try to work with your project.

• MAKE

If the whole world runs in the same UNIX terminal, and speaks fluent Bash, then yeah. But why not just become a C/C++ programmer, it's much more fun than Java anyhow.

• Ruby (Various)

Whatever. Niche, slow. Just develop Ruby then, stay away from Java development.

• Python

People use Java where they don't trust Python (anywhere there's money involved). If your system is running Python anyway, you wont even be reading this, unless of course you want the Java money - but are stuck developing Python in some web shop.

• Clojure (Various)

In honour of Stallman, I'll learn Lisp - but for Emacs, not so that I run it upon my VM. I feel that it cheapens the experience.

Advantages:

Maven is great when you need to be up and running quickly and the dependency management is good. Facilities to avoid jar-hell are not bad either. Some of the underlying theory behind Maven is sound. The default lifecycle phases are well thought out and very instructive for anyone wanting to learn build engineering best practices. Despite the poor documentation the discoverability is excellent, try mvn help:help -Ddetail=true to see what I mean. If you know how to read an xsd document then constructing a pom is not that hard.

Disadvantages (the devil is in the detail):

One cannot specify the order of different plugin executions that are bound to the same phase, and any form of non-determinism in computer programming is just plain terrible.

Unlike Ant property values i.e.) ${my.property}, Maven properties are resolved at the start of the build, which is OK if you know what the value will be at the start, but if the property's value is determined somewhere in the middle of your build it is too late to access it, its already been interpreted before it's been assigned so the value will be null or the empty string. This is even the case when the execution that needs the property is executed in a phase after the execution that assigns the property -> tearing my hair out over this one.

If you stick to the "Maven way" everything runs smoothly. As soon as your build digresses from the "Maven way" all hell breaks loose -> expect to get very good at programming bespoke Maven plugins and archetypes for your project, because doing it from scratch will be more efficient than futzing around Maven's constraints.

When working on large projects with many pom files using aggregation (modules in Maven-speak) and inheritance (parents in Maven-speak) there is way too much duplication across builds doing the same or similar things. The Maven xml grammar provides no clear way of distinguishing those members which will be inherited from the parent and those which will not. Expect to be running mvn help:effective-pom every two minutes to figure this one out.

Complex builds with many plugin configurations become bloated and unintelligible. This is more a problem with xml than Maven itself. There are much clearer and more expressive ways of writing a build -> such as an internal DSL in a dynamic language that supports meta-programming ie Gradle, Buildr

Profiles: with great power comes great responsibility. It's just too easy to stick configuration that belongs in the respective deployment environments inside the build itself, which violates the "one binary" principle. Profiles should be designed to emphasise "roles" rather than environments i.e.) the act of deploying from CI to staging rather than the holding the configuration of staging itself.