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

本指南将通过解释这两个工具之间的区别和相似之处，并提供可遵循的步骤来简化此迁移过程。

转换构建可能令人畏惧，但您不必独自完成。如果您遇到困难，可以搜索我们的文档，在我们的社区论坛上发帖，或在我们的Slack 频道上寻求帮助。

为何迁移

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

这些方面的可视化概览可在Maven 与 Gradle 特性比较中找到。

自 Gradle 3.0 以来，Gradle 大力投入以显著加快 Gradle 构建速度，引入了诸如构建缓存、编译避免以及改进的增量 Java 编译器等特性。即使不使用构建缓存，Gradle 现在也比 Maven 快 2-10 倍，适用于绝大多数项目。从 Maven 切换到 Gradle 的深入性能比较和商业案例可在此处找到。

通用指南

Gradle 和 Maven 在如何构建项目方面存在根本差异。Gradle 提供了一个灵活且可扩展的构建模型，将实际工作委托给任务图的执行。Maven 使用固定的线性阶段模型，可以将目标（执行工作的实体）附加到这些阶段。这可能使两者之间的迁移看起来令人畏惧，但迁移过程可能会出乎意料地简单，因为 Gradle 遵循许多与 Maven 相同的约定——例如标准项目结构——并且其依赖管理方式也很相似。

在此，我们为您列出了一系列步骤，遵循这些步骤将有助于您将任何 Maven 构建迁移到 Gradle

将旧的 Maven 构建和新的 Gradle 构建并排放置。您知道 Maven 构建是可行的，所以应该保留它，直到您确信 Gradle 构建也能产生所有相同的 Artifact。这还意味着用户可以在不创建源代码树新副本的情况下尝试 Gradle 构建。

  1. 为 Maven 构建创建构建扫描.

    构建扫描可以更容易地可视化您现有 Maven 构建中发生的情况。对于 Maven 构建，您将能够查看项目结构、使用的插件、构建步骤的时间线等。请将其妥善保存，以便在转换项目时与 Gradle 构建扫描进行比较。

  2. 开发一种机制来验证两个构建是否产生相同的 Artifact。

    这是确保您的部署和测试不会中断至关重要的一步。即使是微小的更改，例如 JAR 文件中清单文件的内容，也可能导致问题。如果您的 Gradle 构建产生与 Maven 构建相同的输出，这将增强您切换的信心，并使实施带来最大好处的更改变得更加容易。

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

    您需要考虑 Gradle 构建输出与 Maven 构建输出之间的一些固有差异。生成的 POM 只包含消费所需的必要信息，并且它们将正确使用 <compile> 和 <runtime> 范围来应对这种情况。您还可能会看到归档文件中文件顺序以及 classpath 上文件顺序的差异。大多数差异都是微小的，但值得找出它们并验证它们是否可接受。

  3. 运行自动转换.

    这将创建所有您需要的 Gradle 构建文件，即使对于多模块构建也是如此。对于更简单的 Maven 项目，Gradle 构建将可以直接运行！

  4. 为 Gradle 构建创建构建扫描.

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

    此时您的构建可能会失败，但这没关系；扫描仍然会运行。比较 Gradle 构建的扫描和 Maven 构建的扫描，然后继续查看此列表以排除故障。

    我们建议您在迁移期间定期生成构建扫描，以帮助您识别和排除问题。如果需要，您还可以使用 Gradle 构建扫描来确定提升构建性能的机会。

  5. 验证您的依赖项并修复任何问题.

  6. 配置集成测试和功能测试.

    只需配置额外的源集即可迁移许多测试。如果您正在使用第三方库，例如FitNesse，请查看 Gradle 插件门户上是否有合适的社区插件可用。

  7. 用 Gradle 等效插件替换 Maven 插件。

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

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

理解构建生命周期

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

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

以下是一些主要的 Maven 阶段及其对应的 Gradle 任务列表

clean

使用基础插件提供的 clean 任务。

compile

使用Java 插件和其他 JVM 语言插件提供的 classes 任务。这会编译所有语言的所有源文件的所有类，并通过 processResources 任务执行资源过滤。

test

使用 Java 插件提供的 test 任务。它会运行单元测试，更具体地说，是构成test 源集的测试。

package

使用基础插件提供的 assemble 任务。这会构建适合项目的任何包；例如，Java 库的 JAR 或传统 Java Web 应用的 WAR。

verify

使用基础插件提供的 check 任务。这会运行所有附加到它的验证任务，通常包括单元测试、任何静态分析任务——例如Checkstyle——以及其他任务。如果您想包含集成测试，则必须手动配置这些测试。

install

使用Maven Publish 插件提供的 publishToMavenLocal 任务。

请注意，Gradle 构建不需要您“安装” Artifact，因为您可以使用更合适的功能，例如跨项目依赖项和复合构建。您应该仅在与 Maven 构建交互时使用 publishToMavenLocal。

Gradle 还允许您针对本地 Maven 缓存解析依赖项，如声明仓库部分所述。

deploy

使用Maven Publish 插件提供的 publish 任务——如果您的构建正在使用较旧的 Maven 插件（ID：maven），请务必切换。这将把您的包发布到所有已配置的发布仓库。即使定义了多个仓库，也有任务允许您发布到单个仓库。

请注意，Maven Publish 插件默认情况下不会发布源码和 Javadoc JAR，但这可以轻松激活，如构建 Java 项目指南中所述。

执行自动转换

Gradle 的init 任务通常用于创建一个新的骨架项目，但您也可以使用它来自动将现有 Maven 构建转换为 Gradle。一旦 Gradle 安装在您的系统上，您只需在项目根目录中运行以下命令即可

> gradle init

从项目根目录运行。这包括解析现有 POM 并生成相应的 Gradle 构建脚本。如果您正在迁移多项目构建，Gradle 还会创建一个 settings 脚本。

您会发现新的 Gradle 构建包含以下内容

  • POM 中指定的所有自定义仓库

  • 您的外部依赖项和跨项目依赖项

  • 构建项目所需的适当插件（仅限于 Maven Publish、Java 和 War 插件中的一个或多个）

有关自动转换功能的完整列表，请参阅构建初始化插件章节。

需要记住的一点是，程序集不会自动转换。这项额外的转换需要一些手动工作。选项包括

如果您的 Maven 构建没有太多插件或自定义步骤，您只需在迁移完成后运行

> gradle build

迁移完成后。这将自动运行测试并生成所需的 Artifact。

迁移依赖项

Gradle 的依赖管理系统比 Maven 更灵活，但它仍然支持仓库、声明的依赖项、范围（Gradle 中的依赖配置）和传递性依赖项等概念。实际上，Gradle 与 Maven 兼容的仓库一起工作，这使得迁移您的依赖项变得容易。

这两个工具之间一个值得注意的区别在于它们如何管理版本冲突。Maven 使用“最近”匹配算法，而 Gradle 选择最新的版本。不过不用担心，您可以对选择哪个版本拥有很多控制权，如管理传递性依赖项中所述。

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

声明依赖项

Gradle 使用与 Maven 相同的依赖标识符组件：groupId、artifactId 和 version。它也支持 classifier。您只需将依赖项的标识符信息替换到 Gradle 的语法中即可，这在声明依赖项章节中有描述。

例如，考虑这个对 Log4J 的 Maven 风格依赖项

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

这个依赖项在 Gradle 构建脚本中会是以下样子

示例 1. 声明一个简单的编译期依赖项
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 插件的项目，而 api 仅适用于专门应用Java Library 插件的项目。

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

runtime

使用 runtimeOnly 配置。

test

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

测试编译所需的依赖项应针对 testImplementation 配置进行声明。仅运行测试所需的依赖项应使用 testRuntimeOnly。

provided

使用 compileOnly 配置。

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

import

import 范围主要用于 <dependencyManagement> 块内，并且仅适用于 POM-only 发布。阅读使用物料清单一节，了解如何复制此行为。

您也可以指定对 POM-only 发布的常规依赖项。在这种情况下，在该 POM 中声明的依赖项被视为构建的正常传递性依赖项。

例如，假设您想将 groovy-all POM 用于测试。它是一个 POM-only 发布，其依赖项列在 <dependencies> 块内。Gradle 构建中的相应配置如下所示

示例 2. 消费 POM-only 依赖项
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'
}

其结果是，groovy-all POM 中所有 compile 和 runtime 范围的依赖项都会添加到测试运行时 classpath 中，而只有 compile 范围的依赖项会添加到测试编译 classpath 中。具有其他范围的依赖项将被忽略。

声明仓库

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

示例 3. 配置构建以使用 Maven Central
build.gradle.kts
repositories {
    mavenCentral()
}
build.gradle
repositories {
    mavenCentral()
}

您还可以使用 repositories {} 块来配置自定义仓库，如仓库类型章节所述。

最后，Gradle 允许您针对本地 Maven 缓存/仓库解析依赖项。这有助于 Gradle 构建与 Maven 构建交互，但如果不需要这种互操作性，则不应使用此技术。如果您想通过文件系统共享已发布的 Artifact，请考虑配置一个带有 file:// URL 的自定义 Maven 仓库。

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

控制依赖项版本

传递性依赖项的存在意味着您很可能在依赖图中出现同一依赖项的多个版本。默认情况下，Gradle 会选择图中依赖项的最新版本，但这并非总是最佳解决方案。这就是它提供了多种机制来控制解析特定依赖项的哪个版本的原因。

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

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

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

排除传递性依赖项

Maven 构建使用排除机制将不需要的依赖项——或不需要的依赖项版本——排除在依赖图之外。您也可以在 Gradle 中执行相同的操作，但这并非一定是正确的做法。Gradle 提供了其他更适合特定情况的选项，因此您确实需要理解排除机制存在的原因，才能正确地迁移它。

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

如果您更关心控制实际解析某个依赖项的哪个版本，请参阅上一节。

处理可选依赖项

您很可能遇到两种关于可选依赖项的情况

  • 您的某些传递性依赖项被声明为可选

  • 您想在项目发布的 POM 中将某些直接依赖项声明为可选

对于第一种情况，Gradle 的行为与 Maven 相同，并简单地忽略任何声明为可选的传递性依赖项。它们不会被解析，并且如果相同的依赖项在依赖图的其他地方作为非可选项出现，它们对所选版本没有影响。

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

使用物料清单 (BOM)

Maven 允许您通过在 packaging 类型为 pom 的 POM 文件中定义 <dependencyManagement> 部分来共享依赖约束。这种特殊类型的 POM（即 BOM）可以导入到其他 POM 中，以便在您的项目中保持库版本的一致性。

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

示例 4. 在 Gradle 构建中导入 BOM
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 Dependencies BOM
2 添加一个版本由该 BOM 定义的依赖项

您可以在从 Maven BOM 导入版本建议一节中了解有关此功能以及 platform() 和 enforcedPlatform() 之间区别的更多信息。

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

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

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

要迁移多模块 Maven 构建，只需遵循以下步骤

  1. 创建与根 POM 的 <modules> 块匹配的 settings 脚本。

    例如，这个 <modules> 块

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

    可以通过向 settings 脚本添加以下行来迁移

    示例 5. 声明哪些项目属于构建的一部分
    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

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

  2. 将跨模块依赖项替换为项目依赖项。

  3. 使用约定插件复制项目继承。

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

在项目之间共享版本

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

迁移 Maven profiles 和 properties

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

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

  • 构建脚本中

  • 根项目目录中的 gradle.properties 文件中

  • $HOME/.gradle 目录中的 gradle.properties 文件中

这些并非全部选项，如果您想了解更多关于如何以及在何处定义 properties 的信息，请查阅构建环境一章。

您需要了解的一个重要行为是，当在构建脚本和其中一个外部 properties 文件中定义了相同的 property 时会发生什么：构建脚本中的值优先。永远如此。幸运的是，您可以模仿 profiles 的概念来提供可覆盖的默认值。

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

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

以下示例展示了使用名为 buildProfile 的项目 property 和仅初始化名为 message 的额外项目 property 的 profile 脚本的基本技术：

示例 6. 在 Gradle 中模仿 Maven profiles 的行为
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 项目 property 的存在
2 应用适当的 profile 脚本，使用脚本文件名中的 buildProfile 值
3 打印出 message 额外项目 property 的值
4 初始化 message 额外项目 property，其值可以在主构建脚本中使用

通过此设置，您可以通过为您正在使用的项目 property（在此示例中为 buildProfile）传递一个值来激活其中一个 profile

输出 gradle greeting
> gradle greeting
foobar
输出 gradle -PbuildProfile=test greeting
> gradle -PbuildProfile=test greeting
testing 1 2 3

您不限于检查项目 properties。您还可以检查环境变量、JDK 版本、构建运行所在的操作系统或您能想到的任何其他因素。

需要记住的一点是，高级条件语句会使构建更难理解和维护，这与它们使面向对象代码复杂化的方式类似。同样适用于 profiles。Gradle 为您提供了许多更好的方法来避免像 Maven 通常要求的那样广泛使用 profiles，例如通过配置相互变体的多个任务。请参阅由Maven 发布插件创建的 publishPubNamePublicationToRepoNameRepository 任务。

有关在 Gradle 中处理 Maven profiles 的更深入讨论，请参阅这篇博客文章。

过滤资源

Maven 有一个称为 process-resources 的阶段，默认绑定了 resources:resources 目标。这为构建作者提供了对各种文件（例如 Web 资源、打包的 properties 文件等）执行变量替换的机会。

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

例如，这是一个配置，它将源文件视为Groovy SimpleTemplateEngine 模板，并为这些模板提供 version 和 buildNumber properties：

示例 7. 通过 processResources 任务过滤资源内容
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，以便失败的集成测试不会自动导致构建失败（因为您可能需要清理资源，例如正在运行的应用程序服务器）。

使用 source sets 可以在 Gradle 中轻松复制此行为，如我们关于Java 和 JVM 项目中的测试的章节所述。然后，您可以配置一个清理任务（例如关闭测试服务器的任务），使其在使用 Task.finalizedBy() 后始终在集成测试运行之后执行，无论它们成功还是失败。

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

Source sets 还为您提供了很大的灵活性，可以决定集成测试源文件的放置位置。您可以轻松地将它们与单元测试放在同一目录中，或者更优选地放在单独的源目录中，例如 src/integTest/java。要支持其他类型的测试，只需添加更多的 source sets 和 Test 任务。

迁移常用插件

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

  • Shade/Shadow

  • Jetty

  • Checkstyle

  • JaCoCo

  • AntRun（见下文）

为什么这很重要？因为许多插件依赖于标准的 Java 约定，所以迁移仅仅是将 Maven 插件的配置复制到 Gradle 中。例如，这是一个简单的 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 配置如下所示：

示例 8. 配置 Gradle Checkstyle 插件
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(…​) 方法指定顺序即可：

示例 9. 控制 checkstyle 任务何时运行
build.gradle.kts
tasks {
    test {
        mustRunAfter(checkstyleMain, checkstyleTest)
    }
}
build.gradle
test.mustRunAfter checkstyleMain, checkstyleTest

如您所见，Gradle 配置通常比相应的 Maven 配置要短得多。您还拥有一个更灵活的执行模型，因为您不再受限于 Maven 的固定阶段。

从 Maven 迁移项目时，不要忘记 source sets。它们通常比 Maven 提供的方法更优雅地处理集成测试或生成的源文件，因此您应将其纳入您的迁移计划中。

Ant 目标

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

示例 10. 调用 Ant 任务
build.gradle.kts
tasks.register("sayHello") {
    doLast {
        ant.withGroovyBuilder {
            "echo"("message" to "Hello!")
        }
    }
}
build.gradle
tasks.register('sayHello') {
    doLast {
        ant.echo message: 'Hello!'
    }
}

甚至原生支持 Ant properties 和 filesets。要了解更多信息，请参阅在 Gradle 中使用 Ant。

更简单明了的方法可能是创建自定义任务类型来替代 Ant 为您所做的工作。然后，您可以更容易地受益于增量构建和其他有用的 Gradle 功能。

了解您不需要哪些插件

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

处理不常见和自定义插件

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

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

  • 使用 Maven 项目对象的插件。

  • 不使用 Maven 项目对象的插件。

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

如果一个插件依赖于 Maven 项目，那么您将不得不重写它。不要从考虑 Maven 插件如何工作开始，而是看看它试图解决什么问题。然后尝试找出如何在 Gradle 中解决该问题。您可能会发现这两个构建模型差异很大，以至于将 Maven 插件代码“转录”到 Gradle 插件中根本不会有效。好的一面是，由于 Gradle 拥有更丰富的构建模型和 API，因此编写插件可能会比原来的 Maven 插件容易得多。

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

进一步阅读

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

最后需要注意的是，本指南仅触及了 Gradle 的一些功能，我们鼓励您通过用户手册的其他章节和我们的分步示例了解其余功能。