The case against Maven?_问答_开发者_运维开发者技术经验分享

Time and time again I've read and heard people frustrated over Maven and how complicated it is. And that it's much easier to use Ant to build code.

However, in order to:

Compile code
Run tests
Package a deployable unit

This is all you need from Maven:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>type something here</groupId>
  <artifactId>type something 开发者_StackOverflowhere</artifactId>
  <version>type something here</version>
</project>

What would be the corresponding minimal Ant build file?

As Aaron says, the problem with Maven is not how it works, it's how it fails.

In Ant, dependency management is a problem you have to solve manually (ignoring Ivy for the moment as it is essentially the Maven approach bolted onto Ant). This can be time-consuming if you have a lot of dependencies but it is a one-time cost. Once you've got your dependencies organised and checked into your version control repository it just works. At least until you have to change the dependencies, which is hopefully infrequently (but there are situations where that's not the case).

Maven "solves" the dependency problem by making dependencies dynamic and therefore avoids much of the up-front cost and makes it easier to change dependencies. The cost of this flexibility is complexity. Maven turns your build into a distributed system and in doing so falls foul of many of the 8 Fallacies of Distributed Computing. Some of these problems are problems more in theory than in practice. For instance, I'm not aware of any cases of Maven repositories being compromised but that doesn't mean that you don't have to be aware of the security implications. Other problems with remote repositories, such as reliability, bandwidth and latency, are more common causes of Maven dissatisfaction.

Maven will cache dependencies locally so that once you have retrieved everything that your project needs, it should avoid repeatedly accessing repositories. But over time, and as the number of developers on a project grows, there will be several occasions on which you need to re-retrieve dependencies. With a default Maven set-up you are out-sourcing dependency management. Will the dependency be available immediately when you need it, or will the server be down? Will it still be available from the remote repository in 6 months? Probably, but it's not within your control.

So the Maven advocates will tell you that you can and should run your own Maven repository to avoid many of the problems caused by distributed dependencies. OK, but at this point we have to stop pretending that Maven is simple. Maintaining your own Maven infrastructure can become quite involved.

Another reason people got angry with Maven in the past is its plugin system. Maven is able to update itself but frequently this would just result in breakage. I believe that this behaviour has been tamed in the most recent releases.

Maven might still be the best solution for certain environments, such as teams that are developing several projects in parallel that have some coupling between them, but it is far from pain-free.

Neither is Ant pain-free but the pain tends to be self-inflicted rather than out of your control. You need to introduce higher level abstractions to keep things manageable. Ant Macros are a useful tool in this respect. With some discipline and sensible conventions (perhaps like those Maven encourages?) you can use Ant effectively for large projects. An Ant build file is like any other program (well, except for the verbose XML syntax), it needs to be maintained and refactored as things change, rather than just hacked until it seems to work. What Ant has in its favour is that is robust, it usually results in repeatable builds and it is well documented.

There is no corresponding minimal ant file. Maven is, to use RoRspeak, opinionated software. It assumes where your code is, where compiled files go, where to put a distributable, how to trigger tests and loads of other tasks. In other words, basically nothing needs to be explicitly defined for maven to be able to complete these tasks.

The problem is, of course, that not everything fits into a pre-determined frame, so it's necessary to do something specific, tools like ant (for which everything is specific, anyway) shine: there's no difference, you just describe what you need. As I understand it, that is a common complaint people have with maven. On the other hand, maven doesn't prevent configuration so it can be tweaked and can use ant if necessary.

I would prefer maven for a new project because I can follow sensible maven conventions, but would use ant build scripts for existing projects.

UPDATE:

Correction: for existing projects, I would take a long, hard look at migrating to maven and only then, if I'm really pushed against the wall, use ant. The more I use maven, the more I realize how valuable a tool it really is and how hard it becomes to justify ant: immediately valuable plugins (i.e., not building blocks, like with ant), standardization (juniors have no problem jumping into a new project and building code), dependency management, integration with Hudson/Jenkins...hard to justify ant any more, except for extreme end-of-project-life builds, at least on the types of projects I work on.

The problem with Maven is not when it works, it's when it breaks. In ant, it's usually obvious how to fix a problem.

With Maven, I need to download the source for the buggy plugin, debug it (which is not trivial), patch it, build a new version of the plugin, deploy that locally (hopefully with a new version). This can lead to have to patch other plugins as well (to update them to use the new version, too).

Also, if Maven is missing a feature, I need to write a whole plugin or use the antrun plugin.

So people have to judge between how easy they can adjust their builds for how Maven works and how long they can wait for a bug fix and how hard it will become to maintain a complex Ant build script.

You already know the answer to (the very oriented body of) your question: there is no Ant equivalent to this minimal POM because, unlike Maven, Ant does not define a set of standards, patterns, conventions, in other words a lingua franca or shared language for project management, that would make it possible so Ant can't beat Maven on this sample.

Does this make Ant more complex than Maven? Somehow, yes, and I believe that most complains about Maven's complexity are due to ignorance ("I know Ant well, I know how to do things in Ant, Ant is simple, I don't know Maven, I don't get it, I don't know how to do things, I feel lost, I feel constrained, I don't want to learn it, Maven is complex.") and FUD. But Maven and Ant are so different that there is no real point at comparing them (and Maven is still much more than Ant + dependency management).

Does writing this help? I'm not sure. Unsatisfied people will keep ranting (and make noise) while satisfied people will (silently) keep using Maven and keep watching it spread like wild fire. In other words, there is no case, just a noisy minority claiming that Maven is complex (please explain me how it makes typical tasks more complicated) and too rigid (because Maven doesn't work the way they want). I'm not saying Maven fits everywhere, I'm just saying there is no case.

So at the end (no offense here) such questions don't change anything and I'll just quote Maven and Ant guys: you’ll never agree. On anything. Period. Deal with it!. (highly recommended post) to conclude:

All I’m saying is: stop ranting. Either come up with non-abstract solutions, or shut up. Ranting is easy. Coming up with solutions using your own solutions is less so.