Gradle相对于Maven的优势

发布时间：2023-06-13 17:55:14

由Echo发表在天码营一、Gradle介绍Gradle和Maven作为自动构建工具，在项目的构建中有着广泛的应用。他们之间有各自的优缺点，这里我

由Echo发表在天码营

一、Gradle介绍

Gradle和Maven作为自动构建工具，在项目的构建中有着广泛的应用。他们之间有各自的优缺点，这里我们讨论下他们在项目构建中的一些区别并进行比较。

首先简单介绍下Gradle和Maven。Maven主要服务于基于java平台的项目构建、依赖管理和项目信息管理。无论是小型的开源类库项目，还是大型的企业级应用；无论是传统的瀑布式开发还是流行的敏捷模式，Maven都能大显身手。Gradle是以groovy语言为基础，面向java应用为主，基于DSL语法的自动化构建工具。

虽然两种构建工具有着很多相似处，但是在依赖管理、构建生命周期、加载构建系统组件等许多方面两者有着许多区别。Maven使用XML来定义生成脚本，而 Gradle构建脚本是用Groovy。用XML的优势在于它可以更方便地定义构建逻辑，但这是比较复杂的步骤。用Groovy的好处是写起来比XML标签要简洁许多。不过熟悉的XML的开发人员比groovy的多，并且复杂的逻辑必须由自己编写。类似于Maven的pom.xml文件，每个Gradle项目都需要有一个对应的build.gradle文件，该文件定义一些任务（task）来完成构建工作，当然，每个任务是可配置的，任务之间也可以依赖，用户亦能配置缺省任务。

二、依赖管理

通常的Maven项目有一个单一的依赖的静态配置，所以一个项目应该只有一个单一的Artifact。因此其具备了简单的特点但同时也由于单一缺乏弹性。 Gradle在这方面的更灵活，可以在创建和处理的时候有多套依赖配置。这里我们举一个例子，原本的Maven POM配置是：

<properties>n <kaptcha.version>2.3</kaptcha.version>n</properties>nn<dependencies>n <dependency>n <groupId>com.google.code.kaptcha</groupId>n <artifactId>kaptcha</artifactId>n <version>${kaptcha.version}</version>n <classifier>jdk15</classifier>n </dependency>n <dependency>n <groupId>org.springframework</groupId>n <artifactId>spring-core</artifactId>n </dependency>n <dependency>n <groupId>org.springframework</groupId>n <artifactId>spring-beans</artifactId>n </dependency>n <dependency>n <groupId>org.springframework</groupId>n <artifactId>spring-context</artifactId>n </dependency>n <dependency>n <groupId>junit</groupId>n <artifactId>junit</artifactId>n </dependency>n</dependencies>n

然后我将其转换成Gradle脚本，结果是惊人的：

dependencies {n compile('org.springframework:spring-core:2.5.6')n compile('org.springframework:spring-beans:2.5.6')n compile('org.springframework:spring-context:2.5.6')n compile('com.google.code.kaptcha:kaptcha:2.3:jdk15')n testCompile('junit:junit:4.7')n}n

我们可以发现配置代码减少为原来的四分之一。这还不算我省略的一些父POM配置。最重要的是依赖的groupId、artifactId、 version，scope甚至是classfier，一点都不少。并且Gradle能够解析现有的Maven POM或者Ivy的XML配置，从而得到传递性以来的信息，并且引入到当前项目中，它也支持排除传递性依赖或者干脆关闭传递性依赖，Gradle当你排除一项任务时，所有依赖于此任务的任务都会自动被排除如果他们之间没有其他依赖关系，这是Maven所不具备的特性。

三、加载构建系统的组件

Maven中每个用于构建的组件（编译/jar等）都作为一个插件，每个插件都有它自己的版本和依赖关系树。 Gradle的构建系统组件都是分散的。 Maven插件的优点是在于可以独立更新，无需整个系统更新。Gradle的模型的优点是编译需要核心组件以外的组件时才下载。与此同时Gradle给了用户足够的自由去定义自己的任务，Gradle每个任务都有一个描述,可以分配到一个组。Maven中插件和命令可以描述。比如Gradle你可以排除任何运行的任务。在Maven中没有通用的排除机制，必须用插件来实现它。而且Gradle具有高级任务排序的特性，任务之间的依赖关系被建立之后能够得到完全控制，因为Gradle具有强大的语言结构来描述任务之间的执行顺序，即使任务并不取决于对方的输出。Gradle支持动态任务创建，有时你想要一个任务的行为取决于或无限价值的大范围的参数。一个很好的表达方式提供这样的任务是任务规则。并且执行任务时，Gradle 在遇到第一次失败时不停止，执行每一个要执行的任务其中所有的任务依赖关系都要被完成且没有失败。任务可以被分配去完成其他任务类似于java中的终结原则。他们总是在另一个任务执行之后运行，不管这个任务是否失败了。可以发现在一个单一的执行中许多失败任务会被很好地记录成一个错误报告并最终被汇总。

四、构建生命周期

Maven提供有限的构建生命周期访问，插件可以连接到生命周期的特定阶段，而且只有在核心插件执行。而Gradle可以访问生成的一部分并允许用Groovy代码进行处理。Gradle Java Plugin也定义了构建生命周期，包括编译主代码、处理资源、编译测试代码、执行测试、上传归档等等任务，Gradle的构建生命周期如下图：

相对于Maven完全线性的生命周期，Gradle的构建生命周期略微复杂，不过也更为灵活，例如jar这个任务是用来打包的，它不像Maven那样依赖于执行测试的test任务，类似的，从图中可以看到，一个最终的build任务也没有依赖于uploadArchives任务。这个生命周期并没有将用户限制得很死，由于Gradle完全是基于灵活的任务模型，因此很多事情包括覆盖现有任务，跳过任务都非常易于实现。而这些事情，在Maven的世界中，实现起来就比较的麻烦，或者说Maven就不希望用户这么做。

除了以上几个Maven核心内容与Gradle的区别，在面向对象输出模式，GUI操作界面、声明元素等方面Gradle也有良好表现。构建输出是构建用户体验的重要部分。在其他大多数构建工具中默认输出对于一个构建作者试图调试一个问题来说是有关联的。这通常会导致一个非常详细的输出会隐藏重要的警告和消息实际上是相关的开发人员运行构建。Gradle的默认输出是针对开发人员运行构建和只显示消息相关的情况下而不是滥用日志输出作为一种进度，例如在执行测试的时候。构建输出为构建用户体验是非常重要的。如果你与外部工具和库集成他们的控制台输出可能非常冗长。Gradle系统中你可以定义每个外部工具结合的日志级别的输出应该被路由。Gradle提供GUI操作界面，这是一个独立的用户界面，可以启动GUI选项，通过自定义日志模式你可以替换它的日志与自己的UI。Gradle有许多细粒度的声明性元素,如SourceSets或Android Product Flavors。它们的核心Gradle DSL然后让Gradle构建语言更加丰富。他们不断构建简洁、易于使用、维护和理解即使你有复杂的需求。Maven没有细粒声明元素，这是Maven极端顽固的主要原因。在Gradle,每个插件都可以提供自己的粗或细粒声明元素。这使你可以提供一个声明性方法甚至定制域。它还允许其他技术集成在Gradle中,让它被更多人使用。

整体来讲，Gradle给人一种简洁灵活的体验，然而必须掌握groovy也是他的问题，而且由于其灵活性，导致人们更容易破坏约定以至于让构建变得难以理解。但是Gradle确实是Maven理念的优秀实现。如果足够了解Groovy，也理解Maven的配置和构建，Gradle会是绝佳选择，尤其是它几乎能和现有的Maven系统无缝集成，而且你也能享受到简洁带来的极大乐趣，相信Gradle作为后起之秀在今后能够被完善的更好。