从 Apache Maven 迁移构建

Apache Maven是一个用于 Java 和其他基于 JVM 的项目的构建工具。通常将现有的 Maven 构建迁移到 Gradle。

本指南将通过解释这两种工具之间的差异和相似之处并提供您可以遵循的步骤来简化此过程，从而帮助完成此类迁移。

转换构建可能会很可怕，但您不必单独完成。如果遇到困难，您可以搜索我们的文档、在我们的社区论坛上发帖，或者访问我们的Slack 频道。

提出移民理由

Gradle 和 Maven 之间的主要区别在于灵活性、性能、用户体验和依赖关系管理。

自 Gradle 3.0 以来，Gradle 投入了大量资金，使 Gradle 构建速度更快，具有构建缓存、避免编译和改进的增量 Java 编译器等功能。对于绝大多数项目，Gradle 现在比 Maven 快 2-10 倍，即使不使用构建缓存也是如此。可以在此处找到从 Maven 切换到 Gradle 的深入性能比较和业务案例。

一般准则

Gradle 和 Maven 对于如何构建项目有着根本不同的看法。 Gradle 提供了一个灵活且可扩展的构建模型，将实际工作委托给任务图的执行。 Maven 使用固定的线性阶段模型，您可以在其中附加目标（完成工作的事情）。这可能会使两者之间的迁移看起来令人生畏，但迁移可能出奇地容易，因为 Gradle 遵循许多与 Maven 相同的约定（例如标准项目结构），并且其依赖项管理以类似的方式工作。

在这里，我们列出了一系列步骤供您遵循，这将有助于促进任何 Maven 构建迁移到 Gradle：

并排保留旧的 Maven 构建和新的 Gradle 构建。您知道 Maven 构建是有效的，因此您应该保留它，直到您确信 Gradle 构建会生成所有相同的工件。这也意味着用户可以尝试 Gradle 构建，而无需创建源树的新副本。

为 Maven 构建创建构建扫描。

构建扫描可以更轻松地可视化现有 Maven 构建中发生的情况。对于 Maven 构建，您将能够看到项目结构、正在使用的插件、构建步骤的时间表等等。将其放在手边，以便您可以在转换项目时将其与 Gradle 构建扫描进行比较。
开发一种机制来验证两个构建是否生成相同的工件。

这是确保您的部署和测试不会中断的至关重要的一步。即使是很小的更改（例如 JAR 中清单文件的内容）也可能会导致问题。如果您的 Gradle 构建生成与 Maven 构建相同的输出，这将使您有信心进行切换，并更轻松地实施可提供最大收益的更改。

这并不意味着您需要在每个阶段验证每个工件，尽管这样做可以帮助您快速识别问题的根源。您应该关注关键输出，例如最终报告以及已发布或部署的工件。

与 Maven 相比，您需要考虑 Gradle 生成的构建输出中的一些固有差异。生成的 POM 将仅包含使用所需的信息，并且它们将针对该场景正确使用<compile>和确定范围。<runtime>您可能还会发现存档中的文件顺序和类路径上的文件顺序存在差异。大多数差异都很小，但值得识别它们并验证它们是否可以接受。
运行自动转换。

这将创建您需要的所有 Gradle 构建文件，甚至对于多模块构建也是如此。对于更简单的 Maven 项目，Gradle 构建将准备好运行！
为 Gradle 构建创建构建扫描。

构建扫描可以更轻松地可视化构建中发生的情况。对于 Gradle 构建，您将能够看到项目结构、依赖项（常规依赖项和项目间依赖项）、正在使用的插件以及构建的控制台输出。

此时您的构建可能会失败，但没关系；扫描仍将运行。将 Gradle 构建的构建扫描与 Maven 构建的构建扫描进行比较，并继续沿着此列表进行故障排除。

我们建议您在迁移期间定期生成构建扫描，以帮助您识别和解决问题。如果需要，您还可以使用 Gradle 构建扫描来识别提高构建性能的机会。
验证您的依赖关系并解决任何问题。
配置集成和功能测试。

通过配置额外的源集可以简单地迁移许多测试。如果您使用第三方库，例如FitNesse，请查看Gradle Plugin Portal上是否有合适的社区插件可用。
将 Maven 插件替换为 Gradle 等效项。

对于流行的插件，Gradle 通常有一个等效的插件可供您使用。您可能还会发现可以用内置 Gradle 功能替换插件。作为最后的手段，您可能需要通过您自己的自定义插件和任务类型重新实现 Maven 插件。

本章的其余部分将更详细地介绍将构建从 Maven 迁移到 Gradle 的特定方面。

了解构建生命周期

Maven 构建基于构建生命周期的概念，该生命周期由一组固定阶段组成。这对于迁移到 Gradle 的用户来说可能是一个挑战，因为构建生命周期是一个新概念。尽管了解 Gradle 构建如何适应初始化、配置和执行阶段的结构很重要，但 Gradle 提供了一个可以模仿 Maven 阶段的辅助功能：生命周期任务。

此功能允许您通过创建仅依赖于您感兴趣的任务的无操作任务来定义自己的“生命周期”。为了使 Maven 用户更容易过渡到 Gradle，基础插件— 由所有 JVM 应用像Java Library Plugin这样的语言插件 — 提供了一组与主要 Maven 阶段相对应的生命周期任务。

以下是一些主要 Maven 阶段以及它们映射到的 Gradle 任务的列表：

clean: 使用clean基本插件提供的任务。
compile: 使用Java Plugin和其他JVM语言插件classes提供的任务。这会编译所有语言的所有源文件的所有类，并通过任务执行资源过滤。processResources
test: 使用testJava插件提供的任务。它运行单元测试，更具体地说，运行构成test源集的测试。
package: 使用assemble基本插件提供的任务。这会构建适合该项目的任何包；例如，Java 库的 JAR 或传统 Java Web 应用程序的 WAR。
verify: 使用check基本插件提供的任务。这会运行附加到它的所有验证任务，通常包括单元测试、任何静态分析任务（例如Checkstyle ）和其他任务。如果您想包含集成测试，则必须手动配置这些测试。
install: 使用Maven Publish PluginpublishToMavenLocal提供的任务。

请注意，Gradle 构建不需要您“安装”工件，因为您可以访问更合适的功能，例如项目间依赖关系和复合构建。您应该仅用于publishToMavenLocal与 Maven 构建进行互操作。

Gradle 还允许您解决对本地 Maven 缓存的依赖关系，如声明存储库部分中所述。
deploy: 使用Maven 发布插件publish提供的任务—如果您的构建正在使用旧版 Maven 插件 (ID:)，请确保从该插件切换。这会将您的包发布到所有配置的发布存储库。即使定义了多个存储库，也有一些任务允许您发布到单个存储库。maven

请注意，默认情况下，Maven 发布插件不会发布源代码和 Javadoc JAR ，但是可以按照 构建 java 项目指南中的说明轻松激活它。

迁移依赖项

Gradle 的依赖管理系统比 Maven 更灵活，但它仍然支持相同的存储库、声明依赖、范围（ Gradle 中的依赖配置）和传递依赖等概念。事实上，Gradle 可与 Maven 兼容的存储库配合使用，这使得迁移依赖项变得很容易。

这两个工具之间的一个显着区别在于它们管理版本冲突的方式。 Maven 使用“最接近”的匹配算法，而 Gradle 选择最新的。不过不用担心，您可以很好地控制选择哪些版本，如管理传递依赖项中所述。

在以下部分中，我们将向您展示如何迁移 Maven 构建的依赖关系管理信息的最常见元素。

声明依赖关系

Gradle 使用与 Maven 相同的依赖项标识符组件：组 ID、工件 ID 和版本。它还支持分类器。您需要做的就是将依赖项的标识符信息替换为 Gradle 的语法，这在“声明依赖项”一章中进行了描述。

例如，考虑 Log4J 的 Maven 风格依赖：

<dependencies>
    <dependency>
        <groupId>log4j</groupId>
        <artifactId>log4j</artifactId>
        <version>1.2.12</version>
    </dependency>
</dependencies>

这种依赖关系在 Gradle 构建脚本中如下所示：

Example 1. Declaring a simple compile-time dependency

build.gradle.kts

dependencies {
    implementation("log4j:log4j:1.2.12")  (1)
}

build.gradle

dependencies {
    implementation 'log4j:log4j:1.2.12'  (1)
}

1	将 Log4J 版本 1.2.12 附加到`implementation`配置（范围）

字符串标识符采用 Maven 值groupId、artifactId和version，尽管 Gradle 将它们称为group、module和version。

上面的示例提出了一个明显的问题：该implementation配置是什么？它是Java 插件提供的标准依赖配置之一，通常用作 Maven 默认compile作用域的替代品。

Maven 范围和 Gradle 标准配置之间的一些差异归结为 Gradle 区分构建模块所需的依赖项和构建依赖于该模块的模块所需的依赖项。 Maven 没有做这样的区分，因此发布的 POM 通常包含库的使用者实际上不需要的依赖项。

以下是主要的 Maven 依赖范围以及您应该如何处理它们的迁移：

compile

Gradle 有两种配置可以用来代替作用域compile：implementation和api。前者适用于任何应用 Java Plugin 的项目，而api仅适用于专门应用Java Library Plugin的项目。

在大多数情况下，您应该简单地使用implementation配置，特别是在构建应用程序或 Web 应用程序时。但是，如果您正在构建库，则可以在构建 Java 库api部分了解应声明哪些依赖项。上面链接的 Java 库插件章节中提供了有关和之间差异的更多信息。apiimplementation

runtime

使用runtimeOnly配置。

test

Gradle 区分编译项目测试所需的依赖项和仅运行项目测试所需的依赖项。

应根据testImplementation配置声明测试编译所需的依赖项。那些仅需要运行测试的应用程序应该使用testRuntimeOnly.

provided

使用compileOnly配置。

请注意，War 插件添加了providedCompile依赖providedRuntime项配置。它们的行为与 WAR 文件略有不同compileOnly，只是确保这些依赖项不会打包在 WAR 文件中。但是，依赖项包含在运行时和测试运行时类路径中，因此如果这是您需要的行为，请使用这些配置。

import

该import范围主要在<dependencyManagement>块内使用，并且仅适用于仅 POM 的出版物。请阅读“使用物料清单”部分，了解有关如何复制此行为的更多信息。

您还可以指定对仅 POM 发布的常规依赖关系。在这种情况下，该 POM 中声明的依赖项将被视为构建的正常传递依赖项。

例如，假设您想使用groovy-allPOM 进行测试。它是一个仅 POM 的发布，在<dependencies>块内列出了自己的依赖项。 Gradle 构建中的适当配置如下所示：

Example 2. Consuming a POM-only dependency

build.gradle.kts

dependencies {
    testImplementation("org.codehaus.groovy:groovy-all:2.5.4")
}

build.gradle

dependencies {
    testImplementation 'org.codehaus.groovy:groovy-all:2.5.4'
}

这样做的结果将是 POM 中的所有依赖项compile和runtime范围依赖项groovy-all都会添加到测试运行时类路径中，而只有compile范围依赖项会添加到测试编译类路径中。与其他范围的依赖关系将被忽略。

声明存储库

Gradle 允许您从任何 Maven 兼容或 Ivy 兼容存储库检索声明的依赖项。与 Maven 不同，它没有默认存储库，因此您必须至少声明一个。为了具有与 Maven 构建相同的行为，只需在 Gradle 构建中配置Maven Central ，如下所示：

Example 3. Configuring the build to use Maven Central

build.gradle.kts

repositories {
    mavenCentral()
}

build.gradle

repositories {
    mavenCentral()
}

您还可以使用该repositories {}块来配置自定义存储库，如存储库类型一章中所述。

最后，Gradle 允许您解决对本地 Maven 缓存/存储库的依赖关系。这有助于 Gradle 构建与 Maven 构建进行互操作，但如果您不需要这种互操作性，则不应使用它。如果您想通过文件系统共享已发布的工件，请考虑使用URL 配置自定义 Maven 存储库file://。

您可能还有兴趣了解 Gradle 自己的依赖项缓存，它的行为比 Maven 更可靠，并且可以由多个并发 Gradle 进程安全地使用。

控制依赖版本

传递依赖关系的存在意味着您可以很容易地在依赖关系图中得到相同依赖关系的多个版本。默认情况下，Gradle 将选择图中依赖项的最新版本，但这并不总是正确的解决方案。这就是为什么它提供了多种机制来控制解决给定依赖项的哪个版本。

在每个项目的基础上，您可以使用：

控制传递依赖一章中列出了更多专门的选项。

如果您想确保多项目构建中所有项目的版本一致性，类似于<dependencyManagement>Maven 中的块的工作方式，您可以使用Java Platform Plugin。这允许您声明一组可应用于多个项目的依赖关系约束。您甚至可以将平台发布为 Maven BOM 或使用 Gradle 的元数据格式。有关如何执行此操作的更多信息，请参阅插件页面，特别是使用平台部分，了解如何将平台应用到同一构建中的其他项目。

排除传递依赖

Maven 构建使用排除来将不需要的依赖项（或不需要的依赖项版本）保留在依赖关系图中。您可以使用 Gradle 做同样的事情，但这不一定是正确的做法。 Gradle 提供了可能更适合特定情况的其他选项，因此您确实需要了解为什么要进行排除才能正确迁移它。

如果您想因与版本无关的原因排除依赖项，请查看有关排除传递依赖项的部分。它向您展示如何将排除附加到整个配置（通常是最合适的解决方案）或依赖项。您甚至可以轻松地将排除应用到所有配置。

如果您对控制实际解析的依赖项版本更感兴趣，请参阅上一节。

处理可选的依赖关系

关于可选依赖项，您可能会遇到两种情况：

您的一些传递依赖项被声明为可选
您想要在项目发布的 POM 中将一些直接依赖项声明为可选

对于第一个场景，Gradle 的行为方式与 Maven 相同，只是忽略任何声明为可选的传递依赖项。如果相同的依赖项作为非可选出现在依赖关系图中的其他位置，则它们不会被解析，并且对所选版本没有影响。

至于将依赖项发布为可选，Gradle 提供了一个更丰富的模型，称为功能变体，它允许您声明库提供的“可选功能”。

使用物料清单 (BOM)

Maven 允许您通过在<dependencyManagement>打包类型为pom.然后可以将这种特殊类型的 POM（BOM）导入到其他 POM 中，以便您在项目中拥有一致的库版本。

Gradle 可以将此类 BOM 用于相同目的，使用基于platform()和enforcedPlatform()方法的特殊依赖语法。您只需以正常方式声明依赖项，但将依赖项标识符包装在适当的方法中，如本示例所示，“导入”Spring Boot 依赖项 BOM：

Example 4. Importing a BOM in a Gradle build

build.gradle.kts

dependencies {
    implementation(platform("org.springframework.boot:spring-boot-dependencies:1.5.8.RELEASE"))  (1)

    implementation("com.google.code.gson:gson")  (2)
    implementation("dom4j:dom4j")
}

build.gradle

dependencies {
    implementation platform('org.springframework.boot:spring-boot-dependencies:1.5.8.RELEASE') (1)

    implementation 'com.google.code.gson:gson' (2)
    implementation 'dom4j:dom4j'
}

1	应用 Spring Boot 依赖项 BOM
2	添加其版本由该 BOM 定义的依赖项

您可以在有关从 Maven BOM 导入版本建议的部分中详细了解此功能以及和之间的platform()区别。enforcedPlatform()

您可以使用此功能将任何依赖项的 POM 中的信息应用<dependencyManagement>到 Gradle 构建，即使是那些没有pom.和platform()都会enforcedPlatform()忽略<dependencies>块中声明的任何依赖项。

迁移多模块构建（项目聚合）

Maven 的多模块构建很好地映射到 Gradle 的多项目构建。尝试相应的示例，了解如何设置基本的多项目 Gradle 构建。

要迁移多模块 Maven 构建，只需执行以下步骤：

<modules>创建与根 POM 块匹配的设置脚本。

例如，这个<modules>块：

<modules>
    <module>simple-weather</module>
    <module>simple-webapp</module>
</modules>

可以通过将以下行添加到设置脚本来迁移：

Example 5. Declaring which projects are part of the build

settings.gradle.kts

rootProject.name = "simple-multi-module"  (1)

include("simple-weather", "simple-webapp")  (2)

settings.gradle

rootProject.name = 'simple-multi-module'  (1)

include 'simple-weather', 'simple-webapp'  (2)

1	设置整个项目的名称
2	配置两个子项目作为此构建的一部分

输出gradle projects

> gradle projects

------------------------------------------------------------
Root project 'simple-multi-module'
------------------------------------------------------------

Root project 'simple-multi-module'
+--- Project ':simple-weather'
\--- Project ':simple-webapp'

To see a list of the tasks of a project, run gradle <project-path>:tasks
For example, try running gradle :simple-weather:tasks

用项目依赖替换跨模块依赖。
使用约定插件复制项目继承。

这基本上涉及创建一个根项目构建脚本，将共享配置注入到适当的子项目中。

如果您想复制在dependencyManagement根 POM 文件部分中声明依赖项版本的 Maven 模式，最好的方法是利用该java-platform插件。您需要为此添加一个专用项目，并在构建的常规项目中使用它。有关此模式的更多详细信息，请参阅文档。

迁移 Maven 配置文件和属性

Maven 允许您使用各种属性来参数化构建。有些是项目模型的只读属性，有些是用户在 POM 中定义的。它甚至允许您将系统属性视为项目属性。

Gradle 具有类似的项目属性系统，尽管它区分了项目属性和系统属性。例如，您可以在以下位置定义属性：

构建脚本
gradle.properties项目根目录中的文件
目录gradle.properties中的一个文件$HOME/.gradle

这些并不是唯一的选项，因此如果您有兴趣了解有关如何以及在何处定义属性的更多信息，请查看“构建环境”一章。

您需要注意的一项重要行为是，当在构建脚本和外部属性文件之一中定义相同的属性时会发生什么：构建脚本值优先。总是。幸运的是，您可以模仿配置文件的概念来提供可覆盖的默认值。

这给我们带来了 Maven 配置文件。这些是根据环境、目标平台或任何其他类似因素启用和禁用不同配置的方法。从逻辑上讲，它们只不过是有限的if陈述。由于 Gradle 有更强大的方法来声明条件，因此它不需要对配置文件提供正式支持（除了依赖项的 POM 中）。正如您将看到的，通过将条件与辅助构建脚本相结合，您可以轻松获得相同的行为。

假设您根据环境有不同的部署设置：本地开发（默认）、测试环境和生产。要添加类似配置文件的行为，您首先要为项目根目录中的每个环境创建构建脚本：profile-default.gradle、profile-test.gradle和profile-prod.gradle。然后，您可以根据您自己选择的项目属性有条件地应用这些配置文件脚本之一。

以下示例演示了使用名为的项目属性buildProfile和配置文件脚本的基本技术，这些脚本仅初始化名为的额外项目属性message：

Example 6. Mimicking the behavior of Maven profiles in Gradle

build.gradle.kts

val buildProfile: String? by project  (1)

apply(from = "profile-${buildProfile ?: "default"}.gradle.kts")  (2)

tasks.register("greeting") {
    // Store the message into a variable, because referencing extras from the task action
    // is not compatible with the configuration cache.
    val message = project.extra["message"]
    doLast {
        println(message)  (3)
    }
}

profile-default.gradle.kts

val message by extra("foobar")  (4)

profile-test.gradle.kts

val message by extra("testing 1 2 3")  (4)

profile-prod.gradle.kts

val message by extra("Hello, world!")  (4)

build.gradle

if (!hasProperty('buildProfile')) ext.buildProfile = 'default'  (1)

apply from: "profile-${buildProfile}.gradle"  (2)

tasks.register('greeting') {
    // Store the message into a variable, because referencing extras from the task action
    // is not compatible with the configuration cache.
    def message = project.message
    doLast {
        println message  (3)
    }
}

profile-default.gradle

ext.message = 'foobar'  (4)

profile-test.gradle

ext.message = 'testing 1 2 3'  (4)

profile-prod.gradle

ext.message = 'Hello, world!'  (4)

1	检查 (Groovy) 是否存在或绑定 (Kotlin)`buildProfile`项目属性
2	`buildProfile`使用脚本文件名中的值应用适当的配置文件脚本
3	`message`打印出额外项目属性的值
4	初始化`message`额外的项目属性，然后可以在主构建脚本中使用其值

完成此设置后，您可以通过传递您正在使用的项目属性的值来激活其中一个配置文件 - buildProfile在本例中：

输出gradle greeting

> gradle greeting
foobar

输出gradle -PbuildProfile=test greeting

> gradle -PbuildProfile=test greeting
testing 1 2 3

您不仅限于检查项目属性。您还可以检查环境变量、JDK 版本、运行构建的操作系统或您能想到的任何其他内容。

需要记住的一件事是，高级条件语句使构建更难以理解和维护，类似于它们使面向对象代码复杂化的方式。这同样适用于配置文件。 Gradle 为您提供了许多更好的方法来避免广泛使用 Maven 经常需要的配置文件，例如通过配置多个互为变体的任务。查看Maven Publish Plugin创建的任务。publishPubNamePublicationToRepoNameRepository

有关在 Gradle 中使用 Maven 配置文件的详细讨论，请参阅这篇博客文章。

过滤资源

Maven 有一个名为的阶段，默认情况下它process-resources有绑定的目标。resources:resources这使构建作者有机会对各种文件（例如 Web 资源、打包属性文件等）执行变量替换。

Gradle 的 Java 插件提供了一个processResources任务来完成同样的事情。这是一个ProcessResources任务，它将文件从配置的资源目录（ src/main/resources默认情况下）复制到输出目录。与任何任务一样ProcessResources，Copy您可以将其配置为执行文件过滤、重命名和内容过滤。

作为示例，下面的配置将源文件视为GroovySimpleTemplateEngine模板，并为这些模板提供version和属性：buildNumber

Example 7. Filtering the content of resources via the processResources task

build.gradle.kts

tasks {
    processResources {
        expand("version" to version, "buildNumber" to currentBuildNumber)
    }
}

build.gradle

processResources {
    expand(version: version, buildNumber: currentBuildNumber)
}

请参阅CopySpec的 API 文档，了解所有可用的选项。

配置集成测试

许多 Maven 构建都包含某种类型的集成测试，Maven 通过一组额外的阶段来支持这些测试：pre-integration-test、integration-test、post-integration-test和verify。它还使用 Failsafe 插件代替 Surefire，以便失败的集成测试不会自动使构建失败（因为您可能需要清理资源，例如正在运行的应用程序服务器）。

这种行为很容易在 Gradle 中使用源集复制，正如我们在 Java 和 JVM 项目中的测试一章中所解释的那样。然后，您可以使用Task.finalizedBy()配置清理任务（例如关闭测试服务器的清理任务），使其始终在集成测试之后运行，无论测试成功还是失败。

如果您确实不希望集成测试构建失败，那么您可以使用Java 测试章节的测试执行部分中描述的Test.ignoreFailures设置。

源集还为您在放置集成测试源文件的位置方面提供了很大的灵活性。您可以轻松地将它们保存在与单元测试相同的目录中，或者更好地保存在单独的源目录中，例如src/integTest/java.要支持其他类型的测试，只需添加更多源集和测试任务即可。

迁移常用插件

Maven 和 Gradle 共享通过插件扩展构建的通用方法。尽管插件系统表面上有很大不同，但它们共享许多基于功能的插件，例如：

阴影/阴影
码头
格子风格
嘉可可
AntRun（见下文）

为什么这很重要？由于许多插件依赖于标准 Java 约定，因此迁移只需在 Gradle 中复制 Maven 插件的配置即可。作为示例，下面是一个简单的 Maven Checkstyle 插件配置：

...
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-checkstyle-plugin</artifactId>
  <version>2.17</version>
  <executions>
    <execution>
      <id>validate</id>
      <phase>validate</phase>
      <configuration>
        <configLocation>checkstyle.xml</configLocation>
        <encoding>UTF-8</encoding>
        <consoleOutput>true</consoleOutput>
        <failsOnError>true</failsOnError>
        <linkXRef>false</linkXRef>
      </configuration>
      <goals>
        <goal>check</goal>
      </goals>
    </execution>
  </executions>
</plugin>
...

迁移到 Gradle 时，可以安全地忽略配置块之外的所有内容。本例对应的Gradle配置如下：

Example 8. Configuring the Gradle Checkstyle Plugin

build.gradle.kts

checkstyle {
    config = resources.text.fromFile("checkstyle.xml", "UTF-8")
    isShowViolations = true
    isIgnoreFailures = false
}

build.gradle

checkstyle {
    config = resources.text.fromFile('checkstyle.xml', 'UTF-8')
    showViolations = true
    ignoreFailures = false
}

Checkstyle 任务会自动添加为check任务的依赖项，其中还包括test.如果你想确保 Checkstyle 在测试之前运行，那么只需使用 MustRunAfter(…)方法指定一个顺序：

Example 9. Controlling when the checkstyle task runs

build.gradle.kts

tasks {
    test {
        mustRunAfter(checkstyleMain, checkstyleTest)
    }
}

build.gradle

test.mustRunAfter checkstyleMain, checkstyleTest

正如您所看到的，Gradle 配置通常比 Maven 的等效配置短得多。您还拥有更加灵活的执行模型，因为您不再受 Maven 固定阶段的限制。

从 Maven 迁移项目时，不要忘记源集。这些通常提供比 Maven 更优雅的解决方案来处理集成测试或生成的源，因此您应该将它们纳入您的迁移计划中。

蚂蚁的目标

许多 Maven 构建依赖 AntRun 插件来自定义构建，而无需实现自定义 Maven 插件的开销。 Gradle 没有等效的插件，因为 Ant 是 Gradle 构建中的一等公民（通过对象）ant。例如，您可以像这样使用 Ant 的 Echo 任务：

Example 10. Invoking Ant tasks

build.gradle.kts

tasks.register("sayHello") {
    doLast {
        ant.withGroovyBuilder {
            "echo"("message" to "Hello!")
        }
    }
}

build.gradle

tasks.register('sayHello') {
    doLast {
        ant.echo message: 'Hello!'
    }
}

甚至 Ant 属性和文件集也是本机支持的。要了解更多信息，请参阅从 Gradle 使用 Ant。

仅创建自定义任务类型来替换 Ant 为您所做的工作可能会更简单、更清晰。然后，您可以更轻松地受益于增量构建和其他有用的 Gradle 功能。

了解您不需要哪些插件

值得记住的是，Gradle 构建通常比 Maven 更容易扩展和自定义。在这种情况下，这意味着您可能不需要 Gradle 插件来替换 Maven 插件。例如，Maven Enforcer 插件允许您控制依赖项版本和环境因素，但这些东西可以在普通的 Gradle 构建脚本中轻松配置。

处理不常见和自定义插件

您可能会遇到 Gradle 中没有对应项的 Maven 插件，特别是如果您或您组织中的某人编写了自定义插件。这种情况依赖于您了解 Gradle（以及可能的 Maven）如何工作，因为您通常必须编写自己的插件。

出于迁移目的，Maven 插件有两种主要类型：

那些使用 Maven 项目对象的。
那些没有的。

为什么这很重要？因为如果您使用后者之一，您可以轻松地将其重新实现为自定义 Gradle 任务类型。只需定义与 mojo 参数对应的任务输入和输出，并将执行逻辑转换为任务操作即可。

如果插件依赖于 Maven 项目，那么你将不得不重写它。不要首先考虑 Maven 插件如何工作，而是看看它试图解决什么问题。然后尝试找出如何在 Gradle 中解决该问题。您可能会发现这两个构建模型非常不同，以至于将 Maven 插件代码“转录”到 Gradle 插件中不会有效。从好的方面来说，该插件可能比原来的 Maven 插件更容易编写，因为 Gradle 具有更丰富的构建模型和 API。

如果您确实需要通过构建脚本或插件来实现自定义逻辑，请查看与插件开发相关的指南。另外，请务必熟悉 Gradle 的Groovy DSL Reference，它提供了有关您将使用的 API 的全面文档。它详细介绍了标准配置块（以及支持它们的对象）、系统中的核心类型（Project、Task等）以及任务类型的标准集。主要入口点是Project接口，因为它是支持构建脚本的顶级对象。

进一步阅读

本章涵盖了特定于将 Maven 构建迁移到 Gradle 的主要主题。剩下的只是迁移期间或迁移后可能有用的其他一些领域：

了解如何配置 Gradle 的构建环境，包括用于运行它的 JVM 设置
了解如何有效地构建您的构建
配置 Gradle 的日志记录并在构建中使用它

最后一点，本指南仅涉及 Gradle 的一些功能，我们鼓励您从用户手册的其他章节和我们的分步示例中了解其余功能。

此页面是否有帮助？