What are the differences between Gradle and Maven?

Question

I would like to know the differences between the Gradle and the Maven?

Answer 1

Gradle vs Maven

I will explain by showing the differences that exist with the Gradle about the Maven. It is interesting to note that they are two tools for the build process of your project in any language of JVM. The Gradle is a more robust and interesting tool than the Maven, and that’s what I’m going to present to.

For years we used the Maven to take care of the automation of the build process. This tool has become a market standard and helped numerous teams. However, we cannot deny that it also has its deficiencies. The choice of XML for the project descriptor has its problems.

Why the Gradle?

The scripts of Gradle are declarative, easy to read, and squeezed. Write code in Groovy instead of XML, and follow the philosophy that the Gradle defines of build-by-Convention significantly reduces the size of a script and is much more readable.

Let’s take a look at what differentiates the Gradle of its competitors: its set of native resources:

Expressive DSL and Rich API

The key to using all the power of the Gradle is to know in depth your API, in it we can find all the classes and understand well everything that the Gradle already delivers us natively to work efficiently and quickly. Like all documentation in the world Java, she has her page HTML to be accessed at any time. Follow the link: Gradle doc;

Gradle is Groovy

Ant and Maven are pure XML, and XML can be very simple first date to write and read, however, over time can become very difficult to maintain and make improvements. Gradle is written in Groovy, a language that uses the best of Java to be as simple and dynamic as possible, for this reason we have a very great facility in writing our build file in script form.

Flexible conventions

One of the great ideas of Gradle is to be flexible about standards for your projects. Each project Java has a basic convention and the Gradle knows exactly where the source code is and the test classes of this convention, and how to compile the code, run unit tests, generate javadoc, and create a release of your code. These tasks are fully integrated into the build lifecycle. If you maintain the same project convention Maven, It will automatically know where the code is, so there is a minimal effort of setting up your part. In fact, your build will only have one line.

Robust dependency management

Gradle provides an infrastructure to manage how project dependencies are resolved, retrieved, and stored. Once they have been downloaded and placed in their local cache, they are made available for your project. A key requirement for builds is reproducibility. Have you ever heard your co-worker say: "But it works on my machine"? Builds have to produce the same result in different environments, regardless of the content of their local cache. Dependency managers like Ivy and Maven cannot yet fully guarantee build reproducibility. Why does this happen? Whenever a dependency is downloaded and stored in the local cache, it does not take into account the origin of the artifact. In situations where the source repository is modified to a project without changing its version, the cache dependency is considered solved, even if the content of the artifact is slightly different.

Scalable builds

In some companies, projects can contain hundreds of modules in their structure. Building and testing small code changes can be time consuming. Due to its clear definition of dependencies between project submodules, Gradle takes care to build only the necessary parts.

To improve boot performance, Gradle can be executed in daemon mode. Subsequent build invocations will call the Gradle, that will already be running in the background.

As a result, you will notice that the build will run approximately 25% faster.

Easy to extend

Most companies have a different way of building, and a different way of solving the same problems. The easiest way to implement custom logic is to write a task. Tasks can be defined directly in your build script, without any difficulty. If you feel your task is getting complex, you can create a class to encapsulate the code, making the structure easy to understand and sustainable.

Integration with other tools

If you are using a tool like the Ant, the Gradle does not force you to fully migrate your build, instead it allows you to import the logic of your script Ant and reuse their targets. The Gradle is 100% compatible with repositories Maven and Ivy.

Community-oriented and corporate support

Gradle is a fully open source solution with Apache License 2.0. After its first release in April 2008, the community embraced the project and gave way to its development. The code is on Github.

The Gradle has the Gradle Inc. as a company directly responsible for the standardization of Gradle and its functionalities, hiring the main commiters of the community and delivering build solutions for every type of company with the Gradle.

Build Contínuo

In version 2.5, a new feature was released to Gradle, the Continuous build, this feature allows you to automatically start a build in response to changes in project code.

The Gradle will not finish the build process, instead will wait for files that are processed by the build to change. When any change is detected, you will run the previous build again with the same task selection.

Completion

Well, that’s a brief introduction to the concept of Gradle and their differences with other build tools. Other tools solve most problems, but they are bureaucratic and not scalable, Gradle has come to solve the problems that are not solved by these tools and be stylish, ie it is an evolution for the build tools, which surely meets all the needs that may appear in a build process.

Source

Answer 2

TL;DR

From a practical point of view, Gradle gives you all the power of a dynamic programming language when compiling, testing and distributing your project, while Maven forces a declarative approach with virtually pre-defined steps.

How build tools help

On a day-to-day basis, these tools will avoid too much repetitive work by typing commands into the console to compile your classes, run tests, and distribute your program in a JAR or WAR.

They will save you from having to understand and decorate numerous commands and parameters or rely on IDE to do the job for you.

They also help standardize your projects using name conventions and directories. This makes it easy for you to find things more easily with each new project you’re going to participate in.

Maven

In general, Maven is easier to understand and use in relatively simple projects.

But he is not so interesting in complex projects where there are not so common scenarios. For example, if at some point in the tests you need to perform certain operations specific to your system, such as restoring a backup to the database, then you will have to go out looking for a plugin or create a new one.

Gradle

Gradle is more flexible in this respect, being useful in companies with a complex development cycle.

Meanwhile, some argue that introducing a programming language ends up greatly increasing the complexity of builds over time, as well as any software, besides being unnecessary.

The main argument against Gradle is that the build should be kept simple and declarative. If you need something else, use shell script or something like that to make the task complex.

Choosing

In practice, the choice between Gradle and Maven ends up depending a lot on personal preference and the context of the project, in the same way that the choice of programming language works.

If your concern is to know which tool you should learn, the answer is both and a little more.

The overwhelming majority of existing projects in companies use old technologies. Commonly, you will find projects that are exported directly from Eclipse or Netbeans, projects compiled using Ant and Maven. Rarely do companies develop projects with Gradle or SBT, unless there is individual initiative of a team. Of course this varies enormously from company to company.