Gradle与Maven的区别

Java生态体系中有三大构建工具：Ant、Maven和Gradle。其中，Ant是由Apache软件基金会维护；Maven这个单词来自于意第绪语（犹太语），意为知识的积累，最初在Jakata Turbine项目中用来简化构建过程；Gradle是一个基于Apache Ant和Apache Maven概念的项目自动化构建开源工具，它使用一种基于Groovy的特定领域语言(DSL)来声明项目设置，抛弃了基于XML的各种繁琐配置。

经过几年的发展，Ant几乎销声匿迹，而Maven由于较为不灵活的配置也渐渐被遗忘，而由于Gradle是基于Ant和Maven的一个优化版本，变得如日中天。

Maven的主要功能主要分为依赖管理系统、多模块构建、一致的项目结构、一致的构建模型和插件机制。这里通过这五个方面介绍两者的不同：

依赖管理系统

在Maven的管理体系中，用GroupID、ArtifactID和Version组成的Coordination唯一标识一个依赖项。任何基于Maven构建的项目自身也必须定义这三项属性，生成的包可以是Jar包，也可以是War包或Ear包。

一个典型的引用如下：

    
        org.springframework.boot
        spring-boot-starter-data-jpa
    
    
        org.springframework.boot
        spring-boot-starter-thymeleaf
    
    
        org.springframework.boot
        spring-boot-starter-test
        test
    

这里 GroupID类似于C#中的namespace或者Java中的package，而ArtifactID相当于Class，Version相当于不同版本，如果Version忽略掉，将选择最新的版本链接。

同时，存储这些组件的仓库有远程仓库和本地仓库之分，远程仓库可以是使用世界公用的central仓库，也可以使用Apache Nexus自建的私有仓库；本地仓库则在本地计算机上。通过Maven安装目录下的settings.xml文件可以配置本地仓库的路径，以及采用的远程仓库地址。Gradle在设计时沿用了Maven这种依赖管理体系，同时也引入了改进，让依赖变得更加简洁：

dependencies {
// This dependency is exported to consumers, that is to say found on their compile classpath.
api 'org.apache.commons:commons-math3:3.6.1'

// This dependency is used internally, and not exposed to consumers on their own compile classpath.
implementation 'com.google.guava:guava:23.0'

// Use JUnit test framework
testImplementation 'junit:junit:4.12'

compile 'org.hibernate:hibernate-core:3.6.7.Final'
testCompile ‘junit:junit:4.+'

}

另外，Maven和Gradle对依赖项的审视也有所不同。在Maven中，一个依赖项有6种scope，分别是compile、provided、runtime、test、system、import。其中compile为默认。而gradle将其简化为4种，compile、runtime、testCompile、testRuntime。如上述代码“testCompile ‘junit:junit:4.+'”，在Gradle中支持动态的版本依赖，在版本号后面使用+号可以实现动态的版本管理。在解决依赖冲突方面Gradle的实现机制更加明确，两者都采用的是传递性依赖，而如果多个依赖项指向同一个依赖项的不同版本时可能会引起依赖冲突，Maven处理起来较为繁琐，而Gradle先天具有比较明确的策略。

多模块构建

在面向服务的架构中，通常将一个项目分解为多个模块。在Maven中需要定义parent POM(Project Object Model)作为一组module的通用配置模型，在POM文件中可以使用标签来定义一组子模块。parent POM中的build配置以及依赖配置会自动继承给子module。

Gradle也支持多模块构建，在parent的build.gradle中可以使用allprojects和subprojects代码块分别定义应用于所有项目或子项目中的配置。对于子模块中的定义放置在settings.gradle文件中，每一个模块代表project的对象实例，在parent的build.gradle中通过allproject或subprojects对这些对象进行操作，相比Maven更显灵活。

allprojects {
task nice << { task -> println "I'm $task.project.name" }
}

执行命令gradle -q nice会依次打印出各模块的项目名称。

一致的项目结构

Maven指定了一套项目目录结构作为标准的java项目结构，Gradle也沿用了这一标准的目录结构。如果在Gradle项目中使用了Maven项目结构的话，在Gradle中无需进行多余的配置，只需在文件中包括apply plugin:'java'，系统会自动识别source、resource、test source、test resource等相应资源。

同时，Gradle作为JVM上的构建工具，也支持Groovy、Scala等源代码的构建，同样功能Maven通过一些插件也能达到目的，但配置方面Gradle更灵活。

一致的构建模型

为了解决Ant中对项目构建缺乏标准化的问题，Maven设置了标准的项目周期，构建周期：验证、初始化、生成原始数据、处理原始数据、生成资源、处理资源、编译、处理类、生成测试原始数据、处理测试原始数据、生成测试资源、处理测试资源、测试编译、处理测试类、测试、预定义包、生成包文件、预集成测试、集成测试、后集成测试、核实、安装、部署。但这种构建周期也是Maven应用的劣势。因为Maven将项目的构建周期限制过严，无法在构建周期中添加新的阶段，只能将插件绑定到已有的阶段上。而Gradle在构建模型上非常灵活，可以创建一个task，并随时通过depends建立与已有task的依赖关系。

插件机制

两者都采用了插件机制，Maven是基于XML进行配置，而在Gradle中更加灵活。