From my point of view, Gradle is a script-based build system. For such a build system, you can define your own tasks based on commands or an API. In Gradle, you can write custom build tasks easily by using Groovy. Gradle provides some basic plugins for a common build workflow of Java projects. Based on this, you do not need to define any task, like the compilation of the Java sources for each project, again and again. But since Gradle is based on tasks that can easily be defined in the build script, you do not have any defined structure or best practice for how you should structure your build script and how you should define information like the project name or the dependencies of a project. Don’t get me wrong: Gradle provides good APIs for all this, but it’s up to the developers to decide where in the build script they, for example, define the dependencies of a project. In addition, you always need to run the build script to get information about the project.
Gradle combines good parts of both tools and builds on top of them with DSL and other improvements. It has Ant’s power and flexibility with Maven’s life-cycle and ease of use. Initially, Gradle used Apache Ivy for its dependency management. Later own it moved to its own native dependency resolution engine. The end result is a tool that was released in 2012 and gained a lot of attention in a short period of time, e.g. Google adopted Gradle as the default build tool for the Android OS.
Pros