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 构建能产生所有相同的工件之前，应该保留它。这也意味着用户可以尝试 Gradle 构建，而无需创建源代码树的新副本。

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

    构建扫描将使您更容易可视化现有 Maven 构建中发生的情况。对于 Maven 构建，您将能够看到项目结构、正在使用的插件、构建步骤的时间线等等。请随身携带此信息，以便在转换项目时与构建扫描进行比较。

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

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

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

    您需要考虑 Gradle 生成的构建输出与 Maven 相比的一些固有差异。生成的 POM 将仅包含用于消费所需的信息，并且它们将为该场景正确使用 <compile> 和 <runtime> 作用域。您可能还会看到归档中文件和类路径上文件的顺序存在差异。大多数差异将是微小的，但值得识别它们并验证它们是否可接受。

  3. 运行自动转换.

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

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

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

    您的构建此时可能会失败，但这没关系；扫描仍会运行。将 Gradle 构建的构建扫描与 Maven 构建的构建扫描进行比较，并继续此列表以解决失败问题。

    我们建议您在迁移期间定期生成构建扫描，以帮助您识别和解决问题。如果您愿意，还可以使用构建扫描来识别提高构建性能的机会。

  5. 验证您的依赖项并修复所有问题.

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

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

  7. 将 Maven 插件替换为 Gradle 等效项。

    对于流行插件，Gradle 通常有可供您使用的等效插件。您可能还会发现可以用内置的 Gradle 功能替换插件。万不得已，您可能需要通过您自己的自定义插件和任务类型重新实现 Maven 插件。

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

理解构建生命周期

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

此功能允许您通过创建不执行操作但只依赖于您感兴趣的任务的任务来定义自己的“生命周期”。为了使 Maven 用户更容易过渡到 Gradle，基本插件（由所有 JVM 语言插件（如Java 库插件）应用）提供了一组与主要 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 构建不需要您“安装”工件，因为您可以访问更合适的功能，例如项目间依赖项和复合构建。您应该只使用 publishToMavenLocal 来与 Maven 构建交互。

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

deploy

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

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

执行自动转换

Gradle 的init 任务通常用于创建新的骨架项目，但您也可以使用它自动将现有 Maven 构建转换为 Gradle。一旦 Gradle 安装在您的系统上，您所要做的就是从根项目目录运行命令

> gradle init

这将解析现有的 POM 并生成相应的 Gradle 构建脚本。如果您正在迁移多项目构建，Gradle 还会创建设置脚本。

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

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

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

  • 构建项目的适当插件（限于一个或多个Maven 发布、Java 和War 插件）

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

需要记住的一点是，组件不会自动转换。此额外转换需要一些手动工作。选项包括

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

> gradle build

这将自动运行测试并生成所需的工件。

迁移依赖项

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

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

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

声明依赖项

Gradle 使用与 Maven 相同的依赖标识符组件：group ID、artifact ID 和 version。它还支持分类器。您只需将依赖项的标识符信息替换为 Gradle 的语法即可，这在声明依赖项章节中有所描述。

例如，考虑以下 Maven 风格的 Log4J 依赖项

<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 库插件的项目。

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

runtime

使用 runtimeOnly 配置。

test

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

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

provided

使用 compileOnly 配置。

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

import

import 范围主要用于 <dependencyManagement> 块中，并且仅适用于仅 POM 的发布。阅读有关使用物料清单的部分，了解如何复制此行为。

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

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

示例 2. 使用仅 POM 的依赖项
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 作用域的依赖项都将添加到测试运行时类路径中，而只有 compile 作用域的依赖项将添加到测试编译类路径中。其他作用域的依赖项将被忽略。

声明仓库

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 构建协同工作，但如果您不需要这种协同工作，则不应使用此技术。如果您想通过文件系统共享发布的工件，请考虑配置一个带有 file:// URL 的自定义 Maven 仓库。

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

控制依赖项版本

传递依赖项的存在意味着您很容易在依赖项图中出现相同依赖项的多个版本。默认情况下，Gradle 将选择图中依赖项的最新版本，但这并非总是正确的解决方案。这就是它提供几种机制来控制解析给定依赖项的哪个版本的原因。

对于每个项目，您可以使用

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

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

排除传递依赖项

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

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

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

处理可选依赖项

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

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

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

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

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

使用物料清单 (BOM)

Maven 允许您通过在 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 构建，即使那些没有 pom 打包类型的依赖项也是如此。platform() 和 enforcedPlatform() 都将忽略 <dependencies> 块中声明的任何依赖项。

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

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

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

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

    例如，这个 <modules> 块

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

    可以通过在设置脚本中添加以下行来迁移

    示例 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 配置文件和属性

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

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

  • 构建脚本

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

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

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

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

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

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

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

示例 6. 在 Gradle 中模拟 Maven 配置文件的行为
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 检查 buildProfile 项目属性是否存在（Groovy）或绑定（Kotlin）
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 发布插件创建的 publishPubNamePublicationToRepoNameRepository 任务。

有关在 Gradle 中使用 Maven 配置文件的更详细讨论，请查看此博客文章。

过滤资源

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

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

例如，这是一个将源文件视为 Groovy SimpleTemplateEngine 模板的配置，为这些模板提供 version 和 buildNumber 属性

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

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

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

源集还为您提供了很大的灵活性，可以放置集成测试的源文件。您可以轻松地将它们保存在与单元测试相同的目录中，或者更优选地，保存在单独的源目录中，例如 src/integTest/java。要支持其他类型的测试，只需添加更多源集和 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 迁移项目时，不要忘记源集。它们通常为处理集成测试或生成源提供比 Maven 更优雅的解决方案，因此您应该将它们纳入您的迁移计划。

Ant 目标

许多 Maven 构建依赖于 AntRun 插件来定制构建，而无需实现自定义 Maven 插件的开销。Gradle 没有等效的插件，因为 Ant 在 Gradle 构建中是第一类公民，通过 ant 对象。例如，您可以像这样使用 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 属性和文件集都原生支持。要了解更多信息，请参阅从 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 插件中将无效。从积极的方面来看，该插件可能比原始 Maven 插件更容易编写，因为 Gradle 具有更丰富的构建模型和 API。

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

延伸阅读

本章涵盖了与将 Maven 构建迁移到 Gradle 相关的主要主题。其余的只是在迁移期间或之后可能有用的一些其他方面

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