February 23, 2010

so you haven't seen complaints about maven?

have you only heard good things?  i'm surprised...

here's some stuff to balance it out.

first, a couple of common complaints:
  • too complex
  • too rigid
  • too buggy
  • too opaque
  • difficult and time-consuming to debug problems
then, a couple of links:
Howard @ tapestry, maven vs ivy
a collection of links on negative maven experiences




then, from the answers of a stackoverflow question on mavens bad rep:

I'm surprised you haven't seen some of the Maven rants. It's a very divisive tool. It's a real love-it-or-hate-it thing. Some people love the dependency-management cleverness and accuse those that don't like it of not getting it, and some people only see the problems that can and do occur with complex distributed dependencies and decide its not worth the hassle.
....
Maven is all-or-nothing.

....
Maven has useless error messages.

....
# 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.
....
Re bullet point 2: It uses elements almost always, attributes almost never, so the XML is even harder to read than Ant's!

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

....
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.
....
To sum up, maven is as far from KISS as it can be.

....
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.
....
Further worse, when things do not work, you are absolutely lost. The documentation sucks, the community is clueless.

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

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

....
I've heard bad things about maven. In fact, it's all I've ever heard about it.

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

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

No comments: