There seems to be a trend in some Software development companies: try and adopt new and "fashionable" build tools for new projects.

It might be a good idea to try and "play" with new technologies/platforms in general.

But if your project has big and demanding customers (e.g. big organizations) you'd better think several times before switching from reliable and proven tool set to new and "exciting". One major example of such relatively new (and rather problematic) tool is Maven, which is now used more and more in place of old good Ant in big Java projects (especially Enterprise).

I will try and compare these two (mostly Java) build tools (or build platforms) on this page:

First thing you notice after you clone a projec based upon Maven is that there are *many* pom.xml (Project Object Model) files in different foalders of the project! And that already gives you an idea how messy this tool is! The more sophisticated your project sturcture the more messy things get with Maven.

In a simple demo source code that accompanies book "Maven: The Definitive guide" (by Sonatype, published by O'Reilly) we already find as many as tree (3) pom.xml files!

ymatv@ymatv:~/work/maven$ find weather/ -name pom.xml -a -type f

If you have a look into one of those pom.xml files you'll immediately notice that they are rather messy (especially those below top level) with many <plugin>, <groupId>, <artifactId> and <configuration> elements.

simple-webapp org.mortbay.jetty maven-jetty-plugin 1.0 1.0 org.apache.maven.plugins maven-compiler-plugin 1.5 1.5 org.apache.maven.plugins maven-jar-plugin true org.apache.maven.plugins maven-surefire-plugin true

Most of those plugins required for even simple project are located somewhere else on Inet and require specific version, configuration, etc.

Things get really complicated and problematic when you first try and run "mvn clean install" on command line.

Worse, many plugins require customization and have dependencies that are not easy to understand and resolve!

At the same time Ant projects have just *one* simple build.xml file with very clear and easy to understand "targets" (typically "init", "compile", "dist", "clean" etc).

Essentially, Ant is XML variant of old good make utility from Unix/BSD/Linux platforms (originally designed by IT pioneers! for first Unix/C projects).

Ant is procedural and it does exactly what developers ask it to do!

You define where your source code, build and target are located and you get everything exactly where you like it/need it to be!!!

Maven, on the contrary has some "hidden" logic someone built-into it, and you have no idea about that.

Some other peoples *conventions* used in projectA may not be suitable/acceptable in projectB!

And that seems to be the Biggest problem with Maven and similar build tools (e.g. Gradle).

Ant does NOT have any "hidden" lifecycles.

You simply define targets and their dependencies *yourself* like you did in (ASM/C/C++) Makefile.

And then you attach a sequence of tasks to each target in build.xml.

Simple, reliable and effective!!!

Maven, on the contrary, extensively uses *conventions* (e.g. where your source code is supposed to be located!)

Which means that, if you do not follow someones *assumed conventions* your project will NOT build!

Also Maven has some hidden "lifecycles" build into it (when you run "mvn install"). And you do not know what is does behind the scene.

Based on my own experience with Ant, Maven, Gradle and Makefile, I would recommend using Ant (or even old good Makefile!) and avoid wasting time debugging Maven configurations and plugins!

If you are willing/prepared to waste many staff-days (aka $$$) in your project, debugging those new build tools like Maven and Gradle, go and do it.

Google boys will be happy to see more people got hooked onto their "advertising agency" crappy code.

On the other hand, if you are about developing *working and reliable* software products, then you'd better use Ant (for Java projects).

Because it is simple, understandable and reliable!!! This is my *personal* opinion based on my *own experience* with those tools/technologies!

P.S. I have recently tried running some demo/examples from Google's latest Android SDK (which is using Gradle now).

And many (or most!) of Google demo "applications" (demo BUGS properly!) simply will NOT build! :-)

Many developers (esp. of mobile devices) have already realized that "Internet advertising agency" called Google, does NOT care much about quality of their software.

Google "boys" simply make money by collecting personal information, hacking into (European) networks/sites and then selling information as well as advertising and getting (well) paid for it by their "business partners" from NSA/CIA.

What does it all has to do with Quality Software development??? Not much, I'm afraid.

Google is essentially Microsoft replacement for 21 century.

Same Bolshevik roots.

Same Bolshevik practices.

Same results (malware and spyware).

P.S. this page has been updated on 2 February 2019, after several *identical* attacks (POST, etc) from several different regions (IPs:,,,, of Bolsheviks/KGB ruled "liliputia" (ex Russia before 1917).