I am going to quickly compare and contrast these 3 ?build? tools (for the Java world). The reason i am going to outline this comparison is a lot of people seem not to understand the difference between these 3.
I put ?build? in inverted commas is because these 3 individually are unique in their own ways. Maven, is more than just a ?build? tool. But most people refer to them as ?build? tool and use them for that particular purpose.
There are many more java oriented ?build? tools available out there like Ivy and Buildr. Also, many more other related build tools which target the whole JVM-based ecosystem such as sbt (Scala), Grape(Groovy), Leiningen (Clojure).
I particular highlight these 3 tools is because over the years, they are the most widely used as time gone past. There are already numerous Ant vs Maven vs Gradle comparisons out there exists in existing blog posts, tech articles, stackoverflow questions and i am not re-inventing the wheel. But rather, i just want to get this off my chest and offer my own personal perspective on this. Put simply, i want to share my thoughts on this topic based on my personal experience and learning gained throughout the years.
Apache Ant
?Configuration over Convention?
Perhaps quite an old-fashioned build tool nowadays (2018) and i certainly remember very well during my university days way back in 2006 my lecturers were well advocating this tool. And even when i started my career nearly 10 years ago now, the company i was working for, the project i was in was using this tool massively. And then i was told it was mainstream.
This tool builds upon the idea of ?Configuration??unlike other tools such as Maven which you?ll see later is by ?Convention?. To work it you need to write/code the ?actions? you want the ?build? process to take. i.e. configuration.
Example:
Maven
Now, lets switch our focus to Maven before jumping on Gradle. Without checking on the actual history of Maven and Gradle, as far as i know Maven existed before Gradle. Not long after Ant, Maven came so popular. So popular that nowadays it is considered the de-facto build tool for all Java projects.
Although, it is exactly not just a build tool but a complete software ?project management system?. In a nutshell, the way it works is it helps you manage your dependencies by storing all artifacts on a repository (Maven Central Repository). You specify your ?build? file (it is called `pom.xml`).
In your pom.xml file you list the dependencies you need. It system features a ?plugin? architecture that allows you to put in place plugins that customizes the build lifecycle process. Not like Ant, Maven uses a convention build lifecycle process. If you want to change aspects of it, you plugin in plugins and specify the configuration details.
Yet still, it is quite rigid and it follows a convention rather than giving you the flexibility to configure things. Hence, Maven is so-called ?Convention over Configuration?.
I see it is as the totally opposite to Ant.
And example here:
Gradle
Finally we are onto Gradle.
From what i can remember, Gradle slowly became popular over the last 3?4 years. Some people are starting to favor Gradle simply because in my own words:
?Gradle has the benefits of both words in that it follows Maven?s convention model but yet offers the flexibility of configuration that Ant has?
So, in other words, Gradle is both Convention & Configuration.
In the past, people use Ant because it is highly flexible with its configuration capabilities (in that you can manually define the build steps to the way you want it to). And people choose Maven because of the simplicity model of following a convention without spending so much time in writing so-called build scripts in Ant.
But what about if you want to follow a convention but yet there are some small parts you want to customize fully.
This is where Gradle comes in. And this is in my opinion why people choose Gradle. Simply for this reason.
Gradle in action:
Another reason why people choose Gradle is that no more XML! Both Ant and Maven are XML based. With Gradle, it is a groovy-based DSL you use. Because it is DSL, developers have the ability to code rather than writing/configuring using tedious XML.
In Summary
