Why does Maven have such a bad rep?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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

Answer 7

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.

Answer 8

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

Answer 9

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.

Answer 10

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.

Answer 11

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

Answer 12

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

Answer 13

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.

Answer 14

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.

Answer 15

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%

Answer 16

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.

Answer 17

Too much magic.

Answer 18

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.

Answer 19

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.

Answer 20

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.

Answer 21

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 )

Answer 22

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.

Answer 23

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.

Answer 24

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.

Answer 25

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.

Answer 26

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.

Answer 27

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.

Answer 28

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

Answer 29

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

Answer 30

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.

Answer 31

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.

Answer 32

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?

Answer 33

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

Answer 34

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.

Answer 35

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?

Answer 36

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.

Answer 37

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.

Answer 38

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.

Answer 39

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