Maven and Ant - the eternal debate

Howard Lewis Ship recently blogged about his woes with Maven, which has predictably triggered a long and interesting discussion/flame war.

I respect Howard a great deal: he has done a great job with Tapesty, which is still one of the most innovative and avant-garde frameworks around. But, personnally, I'll stick with Maven.
From my take, Maven brings a lot of valuable features to the table, such as:

• Declarative dependency management. This is a big plus. Yes, I know Ivy does it too, but, for me, that in itself isn't a good enough reason to change.
• Enforced (or, at least, strongly encouraged) standards and best practices.
• Plugins. Sure, some are a bit dodgy, but a lot work well, and when they do work, they are a lot easier to use than doing the same thing in Ant.

Objectively, a Maven build script isn't always shorter than an equivalent Ant script. A lot of the size seems to come from the dependencies, of course - you can't really hold anything against Maven for that. And (for efficiency reasons, I believe), Maven's style of XML has always ignored attributes, which makes it even more verbose. But you get more bang for your buck with a Maven script.

For larger projects, separating the project into smaller module, each with its own POM file, works fine for me. This has the added advantage of helping ensure that you take the time to think about the structure of your project, and lets you refactor common build scripting elements.

Based on my experience, it comes down to this: basically, if you want total control, use Ant. If you are willing to comply with the Maven way of doing things (and there is a lot that makes sense), then Maven can give you a lot of added functionality free. However, the learning curve is a lot steeper than with Ant. And a complex Ant build script can get pretty scary too (I've seen enough of them!)

Howard has some valid points, though.

Yes, many of the problems do come from the plugins. In my experience, using Maven for a standard build with nothing fancy rarely causes any issues. However, I _have_ had many an issue with particular versions of plugins (Cobertura, I'm looking at you!). And I have been incredibly frustrated by how hard it is to get TestNG tests to run properly.

I like Howard's idea of a frozen set of plugin versions that are guaranteed to work for a particular version of Maven - something like that would fix a lot of the issues with SNAPSHOT-based plugins. Though relying on SNAPSHOTs has always seemed like asking for trouble.

I agree that the Maven documentation has always been pretty poor, and I always have a terrible time trying to find anything there. And some of the plugin documentation is really, really crappy.

There sure is room for improvement. Still, I wouldn't change it, as for me, the advantages of using Maven far outway the inconveniences.

John is a freelance consultant specialising in Enterprise Java, Web Development, and Open Source technologies, currently based in Wellington, New Zealand. Well known in the Java community for his many published articles, John helps organisations to optimize their Java development processes and infrastructures and provides training and mentoring in open source technologies, SDLC tools, and agile development processes. John is principal consultant at Wakaleo Consulting, and runs several Training Courses on open source Java development tools and best practices. John is a DZone MVB and is not an employee of DZone and has posted 58 posts at DZone. You can read more from them at their website.