Trying to build something destined for a JVM? Use Maven.
We know it sucks. We know you hate it. We know you’d prefer Gradle, or buildr, or Ant, or even make.
Tough. Just because Maven sucks is no reason to not use it.
It’s easy to say “but I know Ant,” or “Gradle has a nice declarative syntax,” etc. We know all these things.
The only time you should use a build tool other than Maven is when you’re being forced to (i.e., “your office is telling you to use Ant,” which happens distressingly often) or you’re playing around with a toy project that nobody else will see (which allows you to use Gradle, et al, on a lot of projects, realistically!), or you’re working with a community where everyone willingly and enthusiastically agrees to use some other tool.
For any project with real visibility to other people – like, a library that someone other than you will use – Maven’s your build tool, for better or for worse, even if you’re able to make a build that yields something that looks like it was built from Maven (and yes, Reinier, I’m looking at you.)
Why?
Well, let’s think about it.
Ant is good, okay? It’s an excellent general-purpose scripting environment (if you ignore the XML aspect), and has worked admirably for a long time; it is well-known. However, it leaves everything up to you; every project is, essentially, a custom build.
The build might support versioned artifacts. The build might be able to support dynamic dependencies. The build might run tests as a standard build process. The build might support targeted profiles. The build might be able to publish artifacts publicly. The build might be able to generate documentation.
That’s an awful lot of “mights.” Ant can do all of these things, no doubt (been there, done that, have the t-shirt) but the fact that every build is custom should scream “this is a problem.”
It’s easy to standardize Ant builds, too, but that’s an artificial imposition; Maven’s best feature is that it more or less nudges you in the right direction by default, requiring you to do extra stuff to not have decent project build phases, executed in the right order, with the right capabilities.
Since people are essentially lazy, they naturally end up doing what causes them the least work, therefore Maven’s more-or-less-sensible defaults win.
That means you win.
Other build tools allow the Maven defaults and capabilities, without the Maven XML, of course. This is a strength, but the fact is that support for the other build tools is spotty; Maven is common enough that it’s everywhere, and you’re not going to have to wonder if Maven builds are supported by your toolset.
Your tools do support Maven. Period. (If you’re using Eclipse, that tool set support may be spotty, but what do you care? You’re using Eclipse. The rabbit’s already dead. And yes, I appreciate very subtle irony. Sue me.)
Why give in?
You don’t have to; you have your own projects and your own rules.
It could be argued that accepting Maven is “giving in” and not insisting on better tools. If that’s how you feel, that’s great; you don’t need my approval, certainly. But on the other hand, my goals in working with a project are usually “produce artifacts people can use,” not “explore neat new tools;” because I’m focused on yielding artifacts and not process, the tools I choose are focused on the same thing.
I’d strongly suggest you do the same.
Author’s Note: Another repost.