Maven does those two things pretty well, though the documentation part has a large number of bugs that makes keeping
the documentation up-to-date problematic.

Anyway, measured by my Four Principals, Maven falls shorts:

Simplicity - this isn't even on the horizon in Maven-land. If you deviate even a tiny bit from Maven's one-true-path, you are lost! The complexity of plugins, class-loaders, XML documents that are Jelly programs in disguise, lack of documentation, etc., etc. means that doing something trivial can take hours of guesswork. Some parts of this "release candidate" have obviously not even been given a cursory test. Certainly the internals of most plugins are a maze of Ant, Jelly, properties and such, seemingly without end.

This could be somewhat addressed by documentation, but there is a pitiful amount and what there is, is out of date. Understanding multi-project (the whole point of Maven you would think) is a total challenge, addressed only by endless experimentation.

Consistency - I guess this is hard to guage; do you write your own plugin? Write ad-hoc Jelly script? Write and use an Ant task?

Efficiency - Maven is sluggish, chews memory, tends to repeat operations needlessly. I could comment on the volume of downloads that occur (for plugins, for libraries the plugins depend on) but that actually isn't an issue, after you run Maven the first time. However, for HiveMind, I've taken to leaving the room while I perform my dist build ... and it's only two small projects.

One concrete example: when using Maven, I could only get my unit tests to work by turning fork on. With Ant, I'm able to run the unit tests without forking. That's a huge difference.

Feedback - Can you say "NullPointerException"?

What I've accomplished in two days using Ant 1.6 will serve me well for HiveMind and for Tapestry ... and beyond. I think we'll be able to get a significant amount of Maven's functionality in a small, finite, understandable package, and be able to use it on the vast majority of pure Java projects.

I hate to bash the Maven project ... but what I see in Maven is a good, simple, core idea that's spiralled down the wrong path by trying to be everything to everyone. That's a lesson I'm taking to heart as I build something that suits my needs better.

I think the example of the ibiblio dependency is a perfect case of why Maven makes so much sense. Instead of my having to wade through pages of idiosyncratically linked ant build files in HiveMind, Maven standardizes the process. The point is not only to make it easier for the person who developes the code, although it certainly does that in many cases. The flip side of that coin is making it easier for other developers using your code. Granted, many people don't know Maven yet. With an equal understanding of ant and Maven, though, I'd argue that it's much simpler to jump on to a project and build it quickly and easily *and* to understand the build process. I'm still trying to figure out the HiveMind build process to build my own app, and it's not a process I'm looking forward to!

If you've ever used things like the Maven Eclipse plugin, the benefits become abundantly clear if you ask me. Saves people from writing the same ant code in slightly different ways all over the world!

I really, really, really tried hard to like Maven. I don't. It gets in my way, and is unpredictable from release to release. It was hindering my progress, more so than the effort of creating my own Ant scripts. Is Ant perfect? Far from it. But, for me at least, Maven is simply a worse option.

A truly object-oriented solution, where the "build files" or "description files" are, in objects (perhaps Groovy scripts or classes) would be wonderful. But I'm going to let someone else fight that battle.

The HiveBuild stuff is sufficient for building HiveMind and for building Tapestry and I'm not saying the world should run on it. Again, I can only fight so many fires.

A word of warning about not forking a JVM for unit tests: this is a dangerous thing to do if you use statics in your tests (which you probably do because JUnit doesn't leave you much choice). Make sure you reinitialize them before each run.

Strange that this comment still gets a lot of views. Ant 1.6.2 has an option to fork once for an entire test suite ... I use that option.

In terms of statics though ... I almost never use those. What do you put in statics? Singletons. What is HiveMind for? Managing singletons. Use of HiveMind (or any other DI container) gets you away from suspect practices like relying on statics.

I'd advocate revisiting this decision with the advent of Maven2. I am just getting started with Tapestry, by way of Trails. I wouldn't even have bothered looking at Trails except that it uses M2. I just don't use Ant any more. What some call flexibility is spelled h-e-a-d-a-c-h-e for people that are using source code from framework dependencies as documentation to learn the framework. For instance, how do I generate IDEA project descriptors in Ant so I can generate the module descriptor and include it in my project as a dependency (instead of a jar with attached source)? Even in the extremely rare case it is in a particular build.xml, why should I even have to look for it?

It would be arrogant to judge your decision to stop using Maven, but Maven2 is a big improvement and I believe either version provides non-core developers of a given source tree a better chance of getting what they need out of it, being productive more quickly, and in the end, solidifying a stronger community around the product.

On Maven 2: I absolutely use it now every single day, at at least 90% of the time I like it. My only caveat is that for some things that I know how to do in Ant or Maven 1, I can't quite figure out how to do in Maven 2 ... there's a position where you go from using Maven 2 as a tool to appeasing it like a petty god. :-) But I do all my new work in Maven 2 without hesitation.