Gradle系列：深入了解Gradle和Maven的区别

素颜马尾好姑娘i 2023-10-02 11:17 59阅读 0赞

### 文章目录 ###

*  前言
 *  简介
 *   *  gradle和maven的比较
     *  可扩展性
     *  性能比较
     *  增量构建
     *  构建缓存
     *  Gradle守护进程
     *  依赖的区别
     *  从maven迁移到gradle
     *   *  先看下怎么引入这三个plugin：
     *  自动转换
     *  转换依赖
     *  转换repositories仓库
     *   *  你可以在gradle使用maven的仓库：
         *  我们还可以直接指定maven仓库的地址：
         *  如果你想使用maven本地的仓库，则可以这样使用：
     *  但是mavenLocal是不推荐使用的，为什么呢？
     *  控制依赖的版本
     *   *  依赖关系
         *  注意事项
         *  版本升级
         *  最后看一下如何exclude一个依赖：
     *  多模块项目
     *   *  maven中可以创建多模块项目：
         *  我们可以在gradle中做同样的事情settings.gradle：
     *  profile和属性
     *  资源处理
     *   *  比如我可以执行copy任务：
         *  更加复杂的拷贝：

# 前言 #

*  **文章转载于：** 程序那些事
 *  **原作者微信公众号：** 程序那些事
 *  **原文地址：** [深入了解gradle和maven的区别][gradle_maven]

# 简介 #

*  **Gradle** 和 **Maven** 都可以用来构建 Java 程序，甚至在某些情况下，两者还可以互相转换，那么他们两个的共同点和不同点是什么？
 *   我们如何在项目中选择使用哪种技术呢？一起来看看吧。

## gradle和maven的比较 ##

*  虽然 **Gradle** 和 **Maven**都可以作为 **Java** 程序的构建工具。但是两者还是有很大的不同之处的。我们可以从下面几个方面来进行分析。

## 可扩展性 ##

*  **Google** 选择 **Gradle** 作为 **Android** 的构建工具不是没有理由的，其中一个非常重要的原因就是因为 **Gradle** 够灵活。
 *  一方面是因为 **Gradle** 使用的是 **groovy** 或者 **kotlin** 语言作为脚本的编写语言，这样极大的提高了脚本的灵活性，但是其本质上的原因是 **Gradle** 的基础架构能够支持这种灵活性。
 *  你可以使用 **Gradle** 来构建 **Native** 的 **C/C++** 程序，甚至扩展到任何语言的构建。
 *  相对而言，**Maven** 的灵活性就差一些，并且自定义起来也比较麻烦，但是 **Maven** 的项目比较容易看懂，并且上手简单。
 *   所以如果你的项目没有太多自定义构建需求的话还是推荐使用 **Maven**，但是如果有自定义的构建需求，那么还是投入 **Gradle** 的怀抱吧。

## 性能比较 ##

*  虽然现在大家的机子性能都比较强劲，好像在做项目构建的时候性能的优势并不是那么的迫切，但是对于大型项目来说，一次构建可能会需要很长的时间，尤其对于自动化构建和 **CI** 的环境来说，当然希望这个构建是越快越好。
 *  **Gradle 和 Maven** 都支持并行的项目构建和依赖解析，但是 **Gradle** 的三个特点让 **Gradle** 可以跑的比 **Maven** 快上一点。

## 增量构建 ##

*  **Gradle** 为了提升构建的效率，提出了增量构建的概念，为了实现增量构建，**Gradle** 将每一个 **task** 都分成了三部分，**分别是：** **input** 输入，任务本身和 **output** 输出。
 *  下图是一个典型的 **java** 编译的 **task**。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_0_text_aHR0cDovL3d3dy5mbHlkZWFuLmNvbQ_size_25_color_8F8F8F_t_70][]

*  以上图为例，**input** 就是目标 **jdk** 的版本，源代码等，**output** 就是编译出来的 **class** 文件。
 *  增量构建的原理就是监控 **input** 的变化，只有 **input** 发送变化了，才重新执行 task 任务，否则 **gradle** 认为可以重用之前的执行结果。
 *  所以在编写 **gradle** 的 **task** 的时候，需要指定 **task** 的输入和输出。
 *  并且要注意只有会对输出结果产生变化的才能被称为输入，如果你定义了对初始结果完全无关的变量作为输入，则这些变量的变化会导致 **gradle** 重新执行 **task**，导致了不必要的性能的损耗。
 *  还要注意不确定执行结果的任务，比如说同样的输入可能会得到不同的输出结果，那么这样的任务将不能够被配置为增量构建任务。

## 构建缓存 ##

*  **Gradle** 可以重用同样 **input** 的输出作为缓存，大家可能会有疑问了，这个缓存和增量编译不是一个意思吗？
 *  在同一个机子上是的，但是缓存可以跨机器共享.如果你是在一个 **CI** 服务的话，**build cache** 将会非常有用。因为 **developer 的 build** 可以直接从 **CI** 服务器上面拉取构建结果，非常的方便。

## Gradle守护进程 ##

*  **Gradle** 会开启一个守护进程来和各个 **build** 任务进行交互，优点就是不需要每次构建都初始化需要的组件和服务。
 *  同时因为守护进程是一个一直运行的进程，除了可以避免每次 **JVM** 启动的开销之外，还可以缓存项目结构，文件，**task** 和其他的信息，从而提升运行速度。
 *  我们可以运行 **gradle --status** 来查看正在运行的 **daemons** 进程。
 *  从 **Gradle 3.0** 之后，**daemons** 是默认开启的，你可以使用 **org.gradle.daemon=false 来禁止daemons**。
 *  **我们可以通过下面的几个图来直观的感受一下 gradle 和 maven 的性能比较：**
 *  **使用 gradle 和 maven 构建 Apache Commons Lang 3 的比较：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_0_text_aHR0cDovL3d3dy5mbHlkZWFuLmNvbQ_size_25_color_8F8F8F_t_70 1][]

*  **使用 gradle 和 maven 构建小项目（10个模块，每个模块50个源文件和50个测试文件）的比较：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_0_text_aHR0cDovL3d3dy5mbHlkZWFuLmNvbQ_size_25_color_8F8F8F_t_70 2][]

*  **使用gradle和maven构建大项目（500个模块，每个模块100个源文件和100个测试文件）的比较：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_0_text_aHR0cDovL3d3dy5mbHlkZWFuLmNvbQ_size_25_color_8F8F8F_t_70 3][]

*  可以看到 **gradle** 性能的提升是非常明显的。

## 依赖的区别 ##

*  **gralde 和 maven** 都可以本地缓存依赖文件，并且都支持依赖文件的并行下载。
 *  在 **maven** 中只可以通过版本号来覆盖一个依赖项。而 **gradle** 更加灵活，你可以自定义依赖关系和替换规则，通过这些替换规则，**gradle** 可以构建非常复杂的项目。

## 从maven迁移到gradle ##

*  因为 **maven** 出现的时间比较早，所以基本上所有的 **java 项目都支持 maven**，但是并不是所有的项目都支持 **gradle**。
 *  如果你有需要把 maven 项目迁移到 **gradle** 的想法，那么就一起来看看吧。
 *  根据我们之前的介绍，大家可以发现 **gradle 和 maven** 从本质上来说就是不同的，**gradle** 通过 **task** 的 **DAG** 图来组织任务，而 **maven** 则是通过 **attach** 到 **phases 的 goals** 来执行任务。
 *  虽然两者的构建有很大的不同，但是得益于 **gradle 和 maven** 相识的各种约定规则，从 **maven** 移植到 **gradle** 并不是那么难。
 *  要想从 **maven** 移植到 **gradle**，首先要了解下 **maven 的 build** 生命周期，maven的生命周期包含了 **clean，compile，test，package，verify，install 和 deploy 这几个 phase。**
 *  我们需要将 **maven** 的生命周期 **phase** 转换为 **gradle** 的生命周期 **task**。这里需要使用到 **gradle 的 Base Plugin，Java Plugin 和 Maven Publish Plugin。**

### 先看下怎么引入这三个plugin： ###

plugins {
        
        id 'base'
        id 'java'
        id 'maven-publish'
    }

*  **clean** 会被转换成为 **clean task，compile** 会被转换成为 **classes task**
 *  **test** 会被转换成为 **test task，package** 会被转换成为 **assemble task**
 *  **verify** 会被转换成为 **check task，install** 会被转换成为 **Maven Publish Plugin 中的 publishToMavenLocal task**
 *  **deploy** 会被转换成为 **Maven Publish Plugin 中的publish task**
 *  有了这些 **task** 之间的对应关系，我们就可以尝试进行 **maven 到 gradle** 的转换了

## 自动转换 ##

*  我们除了可以使用 **gradle init** 命令来创建一个 **gradle** 的架子之外，还可以使用这个命令来将 **maven** 项目转换成为 **gradle** 项目，**gradle init** 命令会去读取 **pom** 文件，并将其转换成为 **gradle** 项目。

## 转换依赖 ##

*  **gradle 和 maven 的依赖都包含了 group ID，artifact ID 和版本号。两者本质上是一样的，只是形式不同。**
 *  **我们看一个转换的例子：**

*  **上是一个maven的例子，我们看下gradle的例子怎写：**

dependencies {
        
        implementation 'log4j:log4j:1.2.12'  
    }

*  可以看到 **gradle** 比 **maven** 写起来要简单很多。
 *  注意这里的 **implementation** 实际上是由 **Java Plugin** 来实现的。
 *  我们在 **maven** 的依赖中有时候还会用到 **scope** 选项，用来表示依赖的范围
 *  **我们看下这些范围该如何进行转换：**
    
     *  **compile：**
        
         *  在 **gradle** 可以有两种配置来替换 **compile**，我们可以使用 **implementation** 或者 **api**。
         *  前者在任何使用 **Java Plugin** 的 **gradle** 中都可以使用，而 **api** 只能在使用 **Java Library Plugin** 的项目中使用。
         *  当然两者是有区别的，如果你是构建应用程序或者 **webapp**，那么推荐使用 **implementation**，如果你是在构建 **Java libraries**，那么推荐使用 **api**。
     *  **runtime：**
        
         *  可以替换成 **runtimeOnly** 。
     *  **test：**
        
         *  **gradle** 中的 **test** 分为两种，一种是编译 **test** 项目的时候需要，那么可以使用 **testImplementation**，一种是运行 **test** 项目的时候需要，那么可以使用 **testRuntimeOnly**。
     *  **provided：**
        
         *  可以替换成为 **compileOnly**。
     *  **import：**
        
         *  在 **maven** 中，**import** 经常用在 **dependencyManagement** 中，通常用来从一个 **pom** 文件中导入依赖项，从而保证项目中依赖项目版本的一致性。
 *  **在 gradle 中，可以使用 platform() 或者 enforcedPlatform() 来导入 pom 文件：**

dependencies {
        
        implementation platform('org.springframework.boot:spring-boot-dependencies:1.5.8.RELEASE') 
    
        implementation 'com.google.code.gson:gson' 
        implementation 'dom4j:dom4j'
    }

*  比如上面的例子中，我们导入了 **spring-boot-dependencies**。因为这个 **pom** 中已经定义了依赖项的版本号，所以我们在后面引入 **gson** 的时候就不需要指定版本号了。
 *  **platform 和 enforcedPlatform 的区别在于，enforcedPlatform 会将导入的 pom 版本号覆盖其他导入的版本号：**

dependencies {
        
        // import a BOM. The versions used in this file will override any other version found in the graph
        implementation enforcedPlatform('org.springframework.boot:spring-boot-dependencies:1.5.8.RELEASE')
    
        // define dependencies without versions
        implementation 'com.google.code.gson:gson'
        implementation 'dom4j:dom4j'
    
        // this version will be overridden by the one found in the BOM
        implementation 'org.codehaus.groovy:groovy:1.8.6'
    }

## 转换repositories仓库 ##

*  **gradle** 可以兼容使用 **maven** 或者 **lvy** 的 **repository**。**gradle** 没有默认的仓库地址，所以你必须手动指定一个。

### 你可以在gradle使用maven的仓库： ###

repositories {
        
        mavenCentral()
    }

### 我们还可以直接指定maven仓库的地址： ###

repositories {
        
        maven {
        
            url "http://repo.mycompany.com/maven2"
        }
    }

### 如果你想使用maven本地的仓库，则可以这样使用： ###

repositories {
        
        mavenLocal()
    }

## 但是mavenLocal是不推荐使用的，为什么呢？ ##

*  **mavenLocal** 只是 **maven** 在本地的一个 **cache**，它包含的内容并不完整。比如说一个本地的 **maven repository** **module** 可能只包含了 jar 包文件，并没有包含 **source** 或者 **javadoc** 文件。那么我们将不能够在 **gradle** 中查看这个 **module** 的源代码，因为 **gradle**会首先在 **maven** 本地的路径中查找这个 **module**。
 *  并且本地的 **repository** 是不可信任的，因为里面的内容可以轻易被修改，并没有任何的验证机制。

## 控制依赖的版本 ##

*  如果同一个项目中对同一个模块有不同版本的两个依赖的话，默认情况下 **Gradle** 会在解析完 **DAG** 之后，选择版本最高的那个依赖包。
 *  但是这样做并不一定就是正确的， 所以我们需要自定义依赖版本的功能。
 *  首先就是上面我们提到的使用 **platform() 和 enforcedPlatform()** 来导入 **BOM**（**packaging** 类型是 **POM** 的）文件。

### 依赖关系 ###

*  如果我们项目中依赖了某个 **module**，而这个 **module** 又依赖了另外的 **module**，我们叫做传递依赖。在这种情况下，如果我们希望控制传递依赖的版本，比如说将传递依赖的版本升级为一个新的版本，那么可以使用 **dependency constraints：**

dependencies {
        
        implementation 'org.apache.httpcomponents:httpclient'
        constraints {
        
            implementation('org.apache.httpcomponents:httpclient:4.5.3') {
        
                because 'previous versions have a bug impacting this application'
            }
            implementation('commons-codec:commons-codec:1.11') {
        
                because 'version 1.9 pulled from httpclient has bugs affecting this application'
            }
        }
    }

### 注意事项 ###

*  **dependency constraints** 只对传递依赖有效，如果上面的例子中 **commons-codec** 并不是传递依赖，那么将不会有任何影响。
 *  同时 **Dependency constraints** 需要 **Gradle Module Metadata** 的支持，也就是说只有你的 **module** 是发布在 **gradle** 中才支持这个特性，如果是发布在 **maven** 或者 **ivy** 中是不支持的。

### 版本升级 ###

*  上面讲的是传递依赖的版本升级。同样是传递依赖，如果本项目也需要使用到这个传递依赖的 **module**，但是需要使用到更低的版本（因为默认 **gradle** 会使用最新的版本），就需要用到版本降级了。

dependencies {
        
        implementation 'org.apache.httpcomponents:httpclient:4.5.4'
        implementation('commons-codec:commons-codec') {
        
            version {
        
                strictly '1.9'
            }
        }
    }

*  我们可以在implementation中指定特定的version即可。
 *  **strictly** 表示的是强制匹配特定的版本号，除了**strictly** 之外，还有 **require**，表示需要的版本号大于等于给定的版本号。
 *  **prefer**，如果没有指定其他的版本号，那么就使用 **prefer** 这个。**reject**，拒绝使用这个版本。
 *  除此之外，你还可以使用 **Java Platform Plugin** 来指定特定的 **platform**，从而限制版本号。

### 最后看一下如何exclude一个依赖： ###

dependencies {
        
        implementation('commons-beanutils:commons-beanutils:1.9.4') {
        
            exclude group: 'commons-collections', module: 'commons-collections'
        }
    }

## 多模块项目 ##

### maven中可以创建多模块项目： ###

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

### 我们可以在gradle中做同样的事情settings.gradle： ###

rootProject.name = 'simple-multi-module'  
    include 'simple-weather', 'simple-webapp'

## profile和属性 ##

*  **maven** 中可以使用 **profile** 来区别不同的环境，在 **gradle** 中，我们可以定义好不同的 **profile** 文件，**然后通过脚本来加载他们：**
    
     *  **build.gradle：**

if (!hasProperty('buildProfile')) ext.buildProfile = 'default'  
    
    apply from: "profile-${buildProfile}.gradle"  
    
    task greeting {
        
        doLast {
        
            println message  
        }
    }

*  **profile-default.gradle：**

ext.message = 'foobar'

*  **profile-test.gradle：**

ext.message = 'testing 1 2 3'

**我们可以这样来运行：**

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

## 资源处理 ##

*  在 **maven** 中有一个 **process-resources** 阶段，可以执行 **resources:resources** 用来进行 **resource** 文件的拷贝操作。
 *  在 **Gradle** 中的 **Java plugin** 的 **processResources task** 也可以做相同的事情。

### 比如我可以执行copy任务： ###

task copyReport(type: Copy) {
        
        from file("$buildDir/reports/my-report.pdf")
        into file("$buildDir/toArchive")
    }

### 更加复杂的拷贝： ###

task copyPdfReportsForArchiving(type: Copy) {
        
        from "$buildDir/reports"
        include "*.pdf"
        into "$buildDir/toArchive"
    }

[gradle_maven]: https://www.cnblogs.com/flydean/p/14395436.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_0_text_aHR0cDovL3d3dy5mbHlkZWFuLmNvbQ_size_25_color_8F8F8F_t_70]: https://img-blog.csdnimg.cn/20201028104251422.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_0,text_aHR0cDovL3d3dy5mbHlkZWFuLmNvbQ==,size_25,color_8F8F8F,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_0_text_aHR0cDovL3d3dy5mbHlkZWFuLmNvbQ_size_25_color_8F8F8F_t_70 1]: https://img-blog.csdnimg.cn/20201028205153551.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_0,text_aHR0cDovL3d3dy5mbHlkZWFuLmNvbQ==,size_25,color_8F8F8F,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_0_text_aHR0cDovL3d3dy5mbHlkZWFuLmNvbQ_size_25_color_8F8F8F_t_70 2]: https://img-blog.csdnimg.cn/2020102820530754.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_0,text_aHR0cDovL3d3dy5mbHlkZWFuLmNvbQ==,size_25,color_8F8F8F,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_0_text_aHR0cDovL3d3dy5mbHlkZWFuLmNvbQ_size_25_color_8F8F8F_t_70 3]: https://img-blog.csdnimg.cn/20201028205402145.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_0,text_aHR0cDovL3d3dy5mbHlkZWFuLmNvbQ==,size_25,color_8F8F8F,t_70