• Ant vs Maven vs Gradle (current article)

• Writing Custom Gradle Plugins
• Creating a Fat Jar in Gradle

1. Introduction

1.介绍

In this article, we’ll explore three Java build automation tools that dominated the JVM ecosystem – Ant, Maven, and Gradle.

在本文中，我们将探讨主导JVM生态系统的三种Java构建自动化工具–Ant、Maven和Gradle。

We’ll introduce each of them and explore how Java build automation tools evolved.

我们将逐一介绍这些工具，并探讨Java构建自动化工具是如何演变的。

2. Apache Ant

2.Apache Ant

In the beginning, Make was the only build automation tool available beyond homegrown solutions. Make has been around since 1976 and as such, it was used for building Java applications in the early Java years.

一开始，Make是超越自制解决方案的唯一构建自动化工具。Make自1976年以来一直存在，因此，在Java早期，它被用于构建Java应用程序。

However, a lot of conventions from C programs didn’t fit in the Java ecosystem, so in time Ant took over as a better alternative.

然而，C语言程序中的许多惯例并不适合Java生态系统，因此，随着时间的推移，Ant作为一个更好的选择被取代。

Apache Ant (“Another Neat Tool”) is a Java library used for automating build processes for Java applications. Additionally, Ant can be used for building non-Java applications. It was initially part of Apache Tomcat codebase and was released as a standalone project in 2000.

Apache Ant（”另一个整洁的工具”）是一个 Java 库，用于自动化 Java 应用程序的构建过程。此外，Ant还可用于构建非Java应用程序。它最初是Apache Tomcat代码库的一部分，在2000年作为一个独立的项目发布。

In many aspects, Ant is very similar to Make, and it’s simple enough so anyone can start using it without any particular prerequisites. Ant build files are written in XML, and by convention, they’re called build.xml.

在许多方面，Ant与Make非常相似，而且它足够简单，所以任何人都可以开始使用它而不需要任何特殊的先决条件。Ant的构建文件是用XML编写的，按照惯例，它们被称为build.xml。

Different phases of a build process are called “targets”.

构建过程的不同阶段被称为 “目标”。

Here is an example of a build.xml file for a simple Java project with the HelloWorld main class:

下面是一个简单的Java项目的build.xml文件的例子，该项目有一个HelloWorld主类。

<project>
    <target name="clean">
        <delete dir="classes" />
    </target>

    <target name="compile" depends="clean">
        <mkdir dir="classes" />
        <javac srcdir="src" destdir="classes" />
    </target>

    <target name="jar" depends="compile">
        <mkdir dir="jar" />
        <jar destfile="jar/HelloWorld.jar" basedir="classes">
            <manifest>
                <attribute name="Main-Class" 
                  value="antExample.HelloWorld" />
            </manifest>
        </jar>
    </target>

    <target name="run" depends="jar">
        <java jar="jar/HelloWorld.jar" fork="true" />
    </target>
</project>

This build file defines four targets: clean, compile, jar and run. For example, we can compile the code by running:

这个构建文件定义了四个目标。clean, compile, jar和run。例如，我们可以通过运行来编译代码。

ant compile

This will trigger the target clean first which will delete the “classes” directory. After that, the target compile will recreate the directory and compile the src folder into it.

这将首先触发目标clean，它将删除 “classes “目录。之后，目标compile将重新创建该目录并将src文件夹编译到其中。

The main benefit of Ant is its flexibility. Ant doesn’t impose any coding conventions or project structures. Consequently, this means that Ant requires developers to write all the commands by themselves, which sometimes leads to huge XML build files that are hard to maintain.

Ant的主要好处是其灵活性。Ant不强加任何编码惯例或项目结构。因此，这意味着Ant要求开发人员自己编写所有的命令，这有时会导致巨大的XML构建文件，难以维护。

Since there are no conventions, just knowing Ant doesn’t mean we’ll quickly understand any Ant build file. It’ll likely take some time to get accustomed to an unfamiliar Ant file, which is a disadvantage compared to the other, newer tools.

由于没有约定俗成，仅仅了解Ant并不意味着我们会很快理解任何Ant构建文件。很可能需要一些时间来适应一个陌生的Ant文件，这与其他较新的工具相比是一个缺点。

At first, Ant had no built-in support for dependency management. However, as dependency management became a must in the later years, Apache Ivy was developed as a sub-project of the Apache Ant project. It’s integrated with Apache Ant, and it follows the same design principles.

起初，Ant没有对依赖性管理的内置支持。然而，随着依赖性管理在后来成为一项必须的工作，Apache Ivy被开发为Apache Ant项目的一个子项目。它与Apache Ant集成，并且遵循相同的设计原则。

However, the initial Ant limitations due to not having built-in support for dependency management and frustrations when working with unmanagable XML build files led to the creation of Maven.

然而，由于Ant最初没有对依赖性管理的内置支持，以及在处理无法管理的XML构建文件时的挫折感，导致了Maven的诞生。

3. Apache Maven

3.Apache Maven

Apache Maven is a dependency management and a build automation tool, primarily used for Java applications. Maven continues to use XML files just like Ant but in a much more manageable way. The name of the game here is convention over configuration.

Apache Maven是一种依赖性管理和构建自动化工具，主要用于Java应用程序。Maven继续使用XML文件，就像Ant一样，但使用的方式更易于管理。这里的游戏规则是惯例大于配置。

While Ant gives flexibility and requires everything to be written from scratch, Maven relies on conventions and provides predefined commands (goals).

Ant提供了灵活性，并要求一切从头开始编写，而Maven则依赖惯例，提供预定义的命令（目标）。

Simply put, Maven allows us to focus on what our build should do, and gives us the framework to do it. Another positive aspect of Maven was that it provided built-in support for dependency management.

简而言之，Maven让我们专注于构建工作，并为我们提供了构建的框架。Maven的另一个积极方面是，它为依赖性管理提供了内置支持。

Maven’s configuration file, containing build and dependency management instructions, is by convention called pom.xml. Additionally, Maven also prescribes a strict project structure, while Ant provides flexibility there as well.

Maven的配置文件包含构建和依赖性管理指令，按惯例称为pom.xml。此外，Maven还规定了严格的项目结构，而Ant在这方面也提供了灵活性。

Here’s an example of a pom.xml file for the same simple Java project with the HelloWorld main class from before:

下面是一个pom.xml文件的例子，该文件适用于同一个简单的Java项目，其中有之前的HelloWorld主类。

<project xmlns="http://maven.apache.org/POM/4.0.0" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
      http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>baeldung</groupId>
    <artifactId>mavenExample</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <description>Maven example</description>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

However, now the project structure has been standardized as well and conforms to the Maven conventions:

不过，现在项目结构也已经标准化，符合Maven惯例。

+---src
|   +---main
|   |   +---java
|   |   |   \---com
|   |   |       \---baeldung
|   |   |           \---maven
|   |   |                   HelloWorld.java
|   |   |                   
|   |   \---resources
|   \---test
|       +---java
|       \---resources

As opposed to Ant, there is no need to define each of the phases in the build process manually. Instead, we can simply call Maven’s built-in commands.

与Ant相比，我们不需要手动定义构建过程中的每个阶段。相反，我们可以简单地调用Maven的内置命令。

For example, we can compile the code by running:

例如，我们可以通过运行以下代码来编译。

mvn compile

At its core, as noted on official pages, Maven can be considered a plugin execution framework, since all work is done by plugins. Maven supports a wide range of available plugins, and each of them can be additionally configured.

正如官方页面所指出的，Maven的核心是可以被视为一个插件执行框架，因为所有的工作都是由插件完成的。Maven支持大量的可用插件，并且每个插件都可以进行额外配置。

One of the available plugins is Apache Maven Dependency Plugin which has a copy-dependencies goal that will copy our dependencies to a specified directory.

其中一个可用的插件是Apache Maven依赖性插件，它有一个copy-dependencies目标，将我们的依赖性复制到指定目录。

To show this plugin in action, let’s include this plugin in our pom.xml file and configure an output directory for our dependencies:

为了展示这个插件的作用，让我们在pom.xml文件中包含这个插件，并为我们的依赖项配置一个输出目录。

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-dependency-plugin</artifactId>
            <executions>
                <execution>
                    <id>copy-dependencies</id>
                    <phase>package</phase>
                    <goals>
                        <goal>copy-dependencies</goal>
                    </goals>
                    <configuration>
                        <outputDirectory>target/dependencies
                          </outputDirectory>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

This plugin will be executed in a package phase, so if we run:

这个插件将在package阶段执行，所以如果我们运行。

mvn package

We’ll execute this plugin and copy dependencies to the target/dependencies folder.

我们将执行这个插件，并将依赖项复制到目标/依赖项文件夹。

There is also an existing article on how to create an executable JAR using different Maven plugins. Additionally, for a detailed Maven overview, have a look at this core guide on Maven, where some Maven’s key features are explored.

还有一篇现有文章介绍了如何使用不同的Maven插件创建可执行JAR。此外，要了解详细的Maven概况，请看这篇关于Maven的核心指南，其中探讨了Maven的一些关键特性。

Maven became very popular since build files were now standardized and it took significantly less time to maintain build files, comparing to Ant. However, though more standardized than Ant files, Maven configuration files still tend to get big and cumbersome.

Maven变得非常流行，因为构建文件已经标准化，与Ant相比，维护构建文件的时间明显减少。然而，尽管Maven的文件比Ant的文件更加标准化，但Maven的配置文件仍然容易变得庞大而繁琐。

Maven’s strict conventions come with the price of being a lot less flexible than Ant. Goal customization is very hard, so writing custom build scripts is a lot harder to do, compared with Ant.

Maven的严格约定是以灵活性比Ant差很多为代价的。目标定制非常困难，所以与Ant相比，编写自定义构建脚本要难得多。

Although Maven has made some serious improvements regarding making application’s build processes easier and more standardized, it still comes with a price due to being a lot less flexible than Ant. This lead to the creation of Gradle which combines the best of both worlds – Ant’s flexibility and Maven’s features.

尽管Maven在使应用程序的构建过程更简单、更标准化方面做出了一些重大改进，但它仍然要付出代价，因为它的灵活性比Ant差很多。这导致了Gradle的诞生，它结合了Ant的灵活性和Maven的特性这两个世界的优点。

4. Gradle

4.Gradle

Gradle is a dependency management and a build automation tool that was built upon the concepts of Ant and Maven.

Gradle是一个依赖性管理和构建自动化工具，建立在Ant和Maven的概念之上。。

One of the first things we can note about Gradle is that it’s not using XML files, unlike Ant or Maven.

关于Gradle，我们可以注意到的第一件事是，它没有使用XML文件，不像Ant或Maven那样。

Over time, developers became more and more interested in having and working with a domain-specific language – which, simply put, would allow them to solve problems in a specific domain using a language tailored for that particular domain.

随着时间的推移，开发人员对拥有和使用特定领域的语言越来越感兴趣–简单地说，这将使他们能够使用为特定领域定制的语言来解决该领域的问题。

This was adopted by Gradle, which is using a DSL based either on Groovy or Kotlin. This led to smaller configuration files with less clutter since the language was specifically designed to solve specific domain problems. Gradle’s configuration file is by convention called build.gradle in Groovy, or build.gradle.kts in Kotlin.

这被Gradle所采用，它使用的DSL是基于Groovy或Kotlin。这导致了更小的配置文件，杂乱无章，因为该语言是专门为解决特定领域的问题而设计的。Gradle的配置文件按惯例在Groovy中称为build.gradle，或在Kotlin中称为build.gradle.kts。

Notice that Kotlin offers better IDE support than Groovy for auto-completion and error detection.

注意，Kotlin在自动完成和错误检测方面提供了比Groovy更好的IDE支持。

Here is an example of a build.gradle file for the same simple Java project with the HelloWorld main class from before:

下面是一个build.gradle文件的例子，该文件用于同一个简单的Java项目，其中有之前的HelloWorld主类。

apply plugin: 'java'

repositories {
    mavenCentral()
}

jar {
    baseName = 'gradleExample'
    version = '0.0.1-SNAPSHOT'
}

dependencies {
    testImplementation 'junit:junit:4.12'
}

We can compile the code by running:

我们可以通过运行来编译代码。

gradle classes

At its core, Gradle intentionally provides very little functionality. Plugins add all useful features. In our example, we were using java plugin which allows us to compile Java code and other valuable features.

在其核心部分，Gradle有意提供了非常少的功能。插件增加了所有有用的功能。在我们的例子中，我们使用的是java插件，它允许我们编译Java代码和其他有价值的功能。

Gradle gave its build steps name “tasks”, as opposed to Ant’s “targets” or Maven’s “phases”. With Maven, we used Apache Maven Dependency Plugin, and it’s a specific goal to copy dependencies to a specified directory. With Gradle, we can do the same by using tasks:

Gradle给它的构建步骤命名为 “tasks”，而不是Ant的 “target “或Maven的 “phase”。对于Maven，我们使用Apache Maven依赖性插件，它的具体目标是将依赖性复制到指定目录。使用Gradle，我们可以通过使用任务来做同样的事情。

task copyDependencies(type: Copy) {
   from configurations.compile
   into 'dependencies'
}

We can run this task by executing:

我们可以通过执行这个任务来运行。

gradle copyDependencies

5. Conclusion

5.结论

In this article, we presented Ant, Maven, and Gradle – three Java build automation tools.

在这篇文章中，我们介绍了Ant、Maven和Gradle这三种Java构建自动化工具。

Not surprisingly, Maven holds the majority of the build tool market today.

毫不奇怪，Maven占据了当今构建工具市场的大部分份额。

Gradle, however, has seen good adoption in more complex codebases, for the following reasons:

然而，Gradle在更复杂的代码库中得到了良好的应用，原因如下。

Lots of open-source projects such as Spring are using it now
It is faster than Maven for most scenarios, thanks to its incremental builds
It offers advanced analysis and debugging services

However that Gradle seems to have a steeper learning curve, especially if you’re not familiar with Groovy or Kotlin.

然而，Gradle似乎有一个更陡峭的学习曲线，特别是如果你不熟悉Groovy或Kotlin。

Writing Custom Gradle Plugins

« Previous

Introduction to Gradle