Still, I understand your points. But I think all kind of customization for a specific build (custom build plugins) that have to be adjusted and modified during the lifecycle of a project shuold be done with some kind of script language like groovy and checked into the project repository.

Once that build customization works fine, it can be compiled into a real maven plugin with java and stored in the company maven plugin repo.

Just my 2 cents

To make matters worse, several plugins have bugs which are only “fixed” in (SVN, CVS, etc) but not released.

I’m sure they’re all over the place, but complaining about Ant builds that are impossible to understand sounds an awful lot like complaining about a project or source code that is impossible to understand. Ant is like a programming language, if you use it stupidly, it’ll get confusing. I suppose if you aren’t familiar with how to create an intuitive build process, Maven is more idiot proof… but so are “application builder tools” and their likes. (MS Access, Oracle APEX)

I just can’t see the use in these things (or the problem with doing them in Ant) for a project/team that isn’t huge.

-download dependency source code
(just drop the source jars into svn? also, no worky if you don’t have an internet conn. and… over-use of dependencies is a valid concern.. not something to be encouraged, look at the mess Spring, Spring Security, and other bloated OSS projects have to deal with now. dependencies may help speed things up a little in the short term–but for the ‘users’ of a lib and over the long term, they’re nothing but a bad thing to cause problems)
-run tests
(ant does it fine, if you even need it to, and honestly unless you’re doing a release or commit, mandating the execution of tests every single build can waste time. just test when you need to, testing and building aren’t always done together)
-generate JavaDoc and other documentation
(ant can do it fine. and is it really impossible to “just look” at an ant view in Eclipse and immediately understand how to generate docs by clicking on the task? it couldn’t be easier)
-Start up a test web environment if it is a web product
(install, build/deploy, start? what’s so complicated?)
-view a continuous integration environment
(small teams don’t have the resources to set up, create tests for, and maintain a cont int env, and unless your code base is massive it should be well enough designed that this isn’t a serious need anyway)
-see source control repository details
(other tools do this just fine, not sure what the point is?)
-understand how the project is broken up into modules
(isn’t there documentation or architecture diagrams? and if you’re being tossed into a project with no introduction or assistance, just a ‘here’s your task, good luck figuring it all out for yourself!’ it’s going to suck regardless)

And Maven IS slow. Aren’t compilers and software slow enough as it is without adding extra magic to make the problem worse?

I’m in a corporate environment on a team with multiple java developers, any of whom might in fact need to work on any and all projects at some time or another.

How do you minimize the amount of man-hours needed to maintain project structure, dependencies, and build methodology, and (in our case) do so without a dedicated configuration/build manager? Really it comes down to: How do you maximize the amount of time your development team has for developing the end product?

The answer is to minimize the amount of time it takes to achieve ancillary function X (efficiency), AND ensure that function X is always achieved the same way from project to project (eliminate duplication of effort, and reduce learning curve by maintaining consistency).

Maven seems to fit that bill nearly perfectly.

Still, not wanting to commit without due-diligence I decided to poke around and see what others have to say. There seems to be a LOT of criticism around Maven’s rigidity. Frankly, a lot of it is pure ignorance (Maven’s relatively poor documentation promotes this, unfortunately), but some of it is clearly based on some valid points, and backed up with some detailed experiences.

Truth be told, that has me somewhat concerned. But it flies in the face of what I’ve already experienced, and there exist a number of other articles such as this one which detail the exact opposite experience.

What it _seems_ to boil down to to me is that developers who are not on a team, and tend to be either the masters of their own projects, and possibly even the only developers, seem to argue against Maven, while people who work on teams (particularly with highly “creative” developers), tend to sing the praises of Maven.

In the end, my concerns are outweighed by three facts: (1) experience with Maven so far has been great (for all the reasons mentioned and more); (2) the initial effort required to implement it is nearly zero; (3) the effort required to stop using Maven if it proves to be a problem is effectively zero — just stop using it! We can still go back to Ant if we want to.

I should point out that we are not migrating to Maven from some other established mechanism… right now there is no mechanism (don’t ask). So there is less potential loss than if we were abandoning some existing system.

Also I have an eye on Gradle — it’s too young for me to feel comfortable with it (and lacks some features), but if Maven turns out to be too rigid then Gradle seems to provide the benefits of Maven without the rigidity.

Regarding the myth of the automatically updating dependencies quoted in the previous comment, I documented and disproved this rumoured behaviour here.

Thanks again for a great post!

Ant can do most everything listed above as Maven benefits, if you really need it to (some “benefits” are just distractions and are of trivial importance in the grand scheme of things..). If you have someone over-engineering your Ant build files making them hard to comprehend, don’t blame the tool, blame the idiot.

Bad move switching to Maven. Your original decision to use Ant was correct. Most people dropping Maven are ditching it after using it for a long time (not two days), once they’ve run into a few of those “gotchas” that makes them waste hours or days resolving it. But it takes time to encounter these.

I almost never have to touch our Ant scripts. Much better spending your time working on the actual product instead of blowing hours (or days) on a tool used to build the product. Read some of the Maven horror stories out there. No such stories with Ant. And they aren’t from “Maven newbies”, either! I see no reason to use “Maven”–or any project/example that requires it.

I use maven because I have to, but Ant because I want to.