前言
Apache Maven是用于Java和其他广泛使用的基于JVM的项目的构建工具。目前用户基数庞大，想要使用Gradle的人们经常必须迁移现有的Maven构建。这次我们就来聊一下，两种工具的模型之间的差异和相似之处，并提供简化步骤可以帮助完成迁移。
Gradle和Maven之间的主要区别是灵活性，性能，用户体验和依赖性管理。Maven与Gradle功能比较中提供了这些方面的直观概述。详细的内容，可以查看之前的文章，有对两者做详细的比较。
自Gradle 3.0以来，Gradle投入了大量资金，以使Gradle的构建速度更快，并具有构建缓存，避免编译和改进的增量Java编译器等功能。对于大多数项目，即使不使用构建缓存，Gradle的速度也比Maven快2-10倍。
一般准则
对于如何构建项目，Gradle和Maven有着根本不同的看法。Gradle提供了一个灵活且可扩展的构建模型，该模型将实际工作委托给任务依赖关系图。
Maven使用固定的线性阶段模型，可以在其中附加目标(完成工作的事情)。虽然如此不一致的设计，但Gradle遵循许多与Maven相同的约定(例如标准项目结构)，并且其依赖项管理以类似的方式工作。
注意:建议前期保持gradle和maven的并行，直到熟练掌握gradle的构建之后，才尝试完全替换
迁移步骤
创建一个Maven构建扫描
能够更容易可视化现有Maven构建中发生的情况。熟悉原有的maven项目的所有项目结构、依赖关系、插件。以便可以将其与转换项目时获得的Gradle构建扫描进行比较。
开发一种机制来验证两个构建产生相同的功能包
这是确保部署和测试不中断的至关重要的一步。即使是很小的更改，例如JAR中清单文件的内容，也会引起问题。如果Gradle构建生成的输出与Maven构建生成的输出相同，则这将对切换充满信心，并使更容易实施将带来最大收益的重大更改。
这并不意味着需要在每个阶段都验证每个工件，尽管这样做可以帮助快速确定问题的根源。可以只关注关键输出，例如最终报告以及已发布或部署的工件。
与Maven相比，您需要考虑Gradle产生的构建输出中的某些固有差异。生成的POM将仅包含消耗所需的信息，并且它们将针对该方案正确使用和范围。您可能还会看到存档中文件和类路径中文件顺序的差异。大多数差异都是良性的，但值得识别它们并确认它们是可以的。
运行自动转换
这将创建需要的所有Gradle构建文件，即使对于多模块构建也是如此。对于更简单的Maven项目，Gradle构建将可以运行！
为Gradle构建创建构建扫描
构建扫描将使可视化构建中的事情变得更加容易。对于Gradle构建，能够查看项目结构，依赖关系(常规和项目间的依赖关系)，正在使用的插件以及构建的控制台输出。
此时构建可能会失败，但是没关系；扫描仍将运行。将Gradle生成的生成扫描与Maven生成的生成扫描进行比较，然后继续执行此列表以排除故障。
建议在迁移过程中定期生成构建扫描，以帮助确定问题并排除故障。如果愿意，还可以使用Gradle构建扫描来确定提高构建性能的机会，毕竟，性能首先是切换到Gradle的主要原因。
验证依赖修复问题
配置集成和功能测试
通过配置额外的源集，可以简单地迁移许多测试。
用Gradle等效插件替换Maven插件
后续，我们会去了解常见的替换
理解构建生命周期
Maven构建基于构建生命周期的概念，该概念由一组固定阶段组成。这可能会成为用户迁移到Gradle的障碍，因为它的构建生命周期有所不同，尽管了解Gradle的构建方式如何适合初始化，配置和执行阶段的结构很重要。幸运的是，Gradle具有可以模仿Maven各个阶段的功能：生命周期任务。
使Maven用户更轻松地过渡到Gradle，Base插件-由所有JVM语言应用诸如Java库插件之类的插件提供了一组与主要Maven阶段相对应的生命周期任务。
| maven命令 | gradle任务 | 备注 |
|---|---|---|
| clean | clean | Base插件库中提供 |
| compile | classes | Java插件库中提供 |
| test | test | Java插件库中提供，它仅运行单元测试，或更具体地说，运行组成测试源集的测试。 |
| package | assemble | Base插件库中提供 |
| verify | check | Base插件库中提供 |
| install | publishToMavenLocal | Maven 发布插件库中提供 |
| deploy | publish | Maven 发布插件库中提供 |
执行自动转换
Gradle的init任务通常用于创建新的骨架项目，但也可以使用它将现有的Maven构建自动转换为Gradle。将Gradle安装到系统上后，只需执行以下命令
> gradle init在根项目目录，使用Gradle命令执行初始化任务。这基本上包括解析现有的POM并生成相应的Gradle构建脚本。如果迁移多项目版本，Gradle还将创建一个设置脚本。
新的Gradle构建包括以下内容：
POM中指定的所有自定义存储库
外部和项目间依赖
用于构建项目的适当插件(仅限于Maven Publish，Java和War插件中的一个或多个)
后续会详细了解如何构建初始化插件
可以执行命令，完成构建
> gradle build迁移完成后。这将运行测试并产生所需的组件，而您无需任何额外干预。
依赖移植
Gradle的依赖关系管理系统比Maven的依赖项管理系统更灵活，但它仍支持相同的库，声明的依赖关系，范围(Gradle中的依赖关系配置)和可传递依赖关系的概念。实际上，Gradle与兼容Maven的存储库完美配合，这使得迁移依赖关系变得容易。
注：两种工具之间的显着区别是它们如何管理版本冲突。Maven使用“最接近”的匹配算法，而Gradle选择最新的匹配算法。不过放心，可以自主控制选择哪些版本，如管理传递性依赖项中所述。
依赖声明
Gradle使用与Maven相同的依赖项标识符组件：group ID, artifact ID and version。它还支持分类器。因此，需要做的就是将标识符的依赖项信息替换为Gradle的语法
以Log4J举例说明，Maven依赖：
<dependencies> <dependency> <groupId>log4jgroupId> <artifactId>log4jartifactId> <version>1.2.12version> dependency>dependencies>对应的Gradle构建脚本配置如下：
Groovy build.gradle
dependencies { implementation 'log4j:log4j:1.2.12' }Kotlin build.gradle.kts
dependencies { implementation("log4j:log4j:1.2.12") }Maven三元素为 groupId artifactId version，对应的Gradle为 group, module version.
默认作用域为，Maven的compile
Maven的作用域与Gradle的标准配置之间的一些区别归结为Gradle区分了构建模块所需的依赖性和构建依赖于该模块的模块所需的依赖性。Maven没有这种区别。
以下是主要的Maven依赖范围以及如何处理它们的迁移：
compile
Gradle具有两种可用于代替compile范围的配置：implementation 和api。前者适用于所有应用Java插件的项目，而api仅适用于专门应用Java库插件的项目。
在大多数情况下，只需使用implementation配置，尤其是在构建应用程序或网络应用程序时。但是，如果您要构建Java库，则可以在构建Java库的部分中了解使用api声明哪些依赖项。
runtime
使用runtimeOnly配置
test
Gradle区分了编译项目测试所需的那些依赖项和仅运行它们所需的那些依赖项。
应针对testImplementation配置声明测试编译所需的依赖关系。仅运行测试所需的那些应该使用testRuntimeOnly。
provided
使用compileOnly配置。
请注意，War插件添加了providerCompile和providerRuntime依赖项配置。它们的行为与compileOnly略有不同，只需确保这些依赖关系未打包在WAR文件中。但是，依赖项包括在运行时和测试运行时类路径中，因此，如果需要，请使用这些配置。
import
Gradle可以通过基于platform()和forcedPlatform()方法的特殊依赖项语法，将此类BOM用于相同的目的。
dependencies { implementation platform('org.springframework.boot:spring-boot-dependencies:1.5.8.RELEASE') implementation 'com.google.code.gson:gson' implementation 'dom4j:dom4j'}多模块迁移
Maven的多模块能够很容易迁移到Gradle的多项目构建
创建一个与根POM的块匹配的设置脚本。
例如，以下块：
<modules> <module>simple-weathermodule> <module>simple-webappmodule>modules>可以通过在设置脚本中添加以下行来迁移：
例如：
Groovy settings.gradle
rootProject.name = 'simple-multi-module' include 'simple-weather', 'simple-webapp'> gradle projectsinclude::{snippetsPath}/mavenMigration/multiModule/tests/projects.out用项目依赖项替换跨模块依赖项
软件项目通常将软件组件分解为模块，以提高可维护性并防止强耦合。模块可以定义彼此之间的依赖关系，以在同一项目中重用代码
Groovy build.gradle
dependencies { implementation project(':shared')}根据
web-service项目构建project(':web-service') { dependencies { implementation project(':utils') implementation project(':api') }}
使用跨项目配置复制项目继承
注：详细的内容，可以参考下官方文档，此处还是比较难的。
迁移Maven配置文件和属性
Maven允许使用各种属性对构建进行参数化。一些是项目模型的只读属性，其他是用户在POM中定义的属性。它甚至允许将系统属性视为项目属性。
过滤资源
Maven有一个称为process-resources的阶段，该阶段具有目标资源：默认情况下绑定到它的资源
Gradle的Java插件提供了processResources任务来执行相同的操作。这是一个复制任务，可将文件从配置的资源目录(默认情况下为src / main / resources)复制到输出目录。与任何复制任务一样，您可以对其进行配置以执行文件过滤，重命名和内容过滤
processResources { expand(version: version, buildNumber: currentBuildNumber)}移植公共插件
Maven和Gradle共享一种通过插件扩展构建的通用方法。尽管表面上的插件系统有很大不同，但是它们共享许多基于功能的插件，例如：
Shade/Shadow
Jetty
Checkstyle
JaCoCo
AntRun (see further down)
以checkstyle插件为例，Maven
...<plugin> <groupId>org.apache.maven.pluginsgroupId> <artifactId>maven-checkstyle-pluginartifactId> <version>2.17version> <executions> <execution> <id>validateid> <phase>validatephase> <configuration> <configLocation>checkstyle.xmlconfigLocation> <encoding>UTF-8encoding> <consoleOutput>trueconsoleOutput> <failsOnError>truefailsOnError> <linkXRef>falselinkXRef> configuration> <goals> <goal>checkgoal> goals> execution> executions>plugin>...迁移到Gradle时，可以安全地忽略配置块之外的所有内容。在这种情况下，相应的Gradle配置如下所示：
checkstyle { config = resources.text.fromFile('checkstyle.xml', 'UTF-8') showViolations = true ignoreFailures = false}总结
本篇内容，我们聊了maven到gradle移植过程中的奇奇怪怪的事情。基本上涵盖，但是具体的内容，还需要对应的去了解，仔细点研究。
扫一扫
414
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
