Ant Vs Maven Vs Gradle MSBuild

Official Gradle vs Maven: Feature Comparison Chart

Quick Intro

1. Ant

2. Maven

3. Gradle

4. MSBuild

Conclusion

One point that, thankfully, both approaches have in common is the way dependencies will be resolved. Both Maven and Gradle will download (transitive) dependencies from any artifact repository. Maven uses Maven Central here as the default and Gradle uses JCenter. In addition, any other repository (like a private company repository) can easily be defined. Because artifact repositories follow some common standards, all the mentioned repositories can easily be used in Maven or Gradle.

On the other hand, both tools/build systems have some big disadvantages from my point of view. It’s quite easy to define project metadata and dependencies in Maven, but it’s absolutely horrible to create a highly customized build with Maven. If you want to create asciidoc-based documentation or upload the final artifact to a Java EE server. your POM file will quickly become unreadable. The Maven pom of the Hazelcast project has, for example, more than 1,000 lines. Understanding a 1,000-line XML-based build definition can be very frustrating for a new developer. So, Maven is nice for small modules and APIs, like Apache commons or GSON. Developers can get a quick overview about the project and its dependencies by simply having a look at the POM file. In addition, tools do not need to run a build process/script to get information. The POM file can simply be parsed.

Gradle, on the other hand, provides a lot of flexibility. Since it is based on a script, you can do pretty much everything, and supporting custom build steps is much easier than in Maven. This is very good if you want to deploy your artifacts to a server or create, for example, documentation. But based on the flexibility, a build script can become complex, too. In most big Java projects I've seen in the last few years, only a few developers know how to change something in the Gradle build. In addition, any tool needs to run a Gradle build to get basic information about the project. Since Gradle build scripts are based on a scripting language, it’s impossible to parse them. So, in the end, Gradle is sadly not the perfect solution for building Java projects.

Based on this, I would say that, currently, no Java build tool is the perfect solution for all Java-based projects. Maven is too limited but great for small projects that follow the defined Maven lifecycle and definitions. Gradle, on the other hand, can do everything that you want, but even small projects may differ in its definition because you can structure/define your build description in any way. In addition, you need to run the build to receive information about the project.

Based on these points, I think that there is a way for all the benefits to be simply combined. When having a look at the build systems for JavaScript, you can see a difference. Modern build systems for JavaScript, like gulp, work more or less like Gradle. You can easily define your own custom tasks based on a scripting language. In addition, the metadata of the project is often defined in a separate file. Most projects that I have seen the last few months use bower to define the static metadata of a project. This includes a description of the project (name, description, license, etc.) and its dependencies. Build tools like gulp can now use the information of bower to build the project (yes, this is a very easy description of the internal process). Based on this, I ask myself why Gradle, for example, can’t do the same. Let’s think about a static definition for Java projects and modules that can easily integrated into a Gradle or Maven build. Since such a definition would be used by both tools it would be much easier for developers to learn how to read and use such a static definition. In addition, tools do not need to start any external process, like a build script, to get information about the Java project. For complete projects, you can simply create custom Gradle tasks that internally get all the information of the static definition and reuse it for the real build.

Reference

https://programmingmitra.blogspot.in/2016/05/java-build-tools-comparisons-ant-vs.html

https://dzone.com/articles/maven-vs-gradle-and-the-best-of-both-worlds