Build tool

what：

Build tool（构建工具）是从源代码自动创建可执行应用程序的程序。构建包括将代码编译，链接和打包成可用或可执行的形式。在小项目中，开发人员通常会手动调用构建过程。这对于较大的项目来说是不实际的，在这些项目中，很难跟踪需要构建的内容，构建过程中的顺序和依赖关系。使用自动化工具可以使构建过程更加一致

how：

1、灵活性

谷歌选择Gradle作为Android的官方构建工具 ; 不是因为构建脚本是代码，而是因为Gradle以最基本的方式可扩展的方式建模。Gradle的模型还允许它用于C / C ++的本地开发，并且可以扩展到涵盖任何生态系统。例如，Gradle的设计考虑了使用其Tooling API嵌入。

Gradle和Maven都提供了约定优于配置。然而，Maven提供了一个非常严格的模型，使定制变得乏味，有时甚至是不可能的。虽然这可以使任何给定的Maven构建更容易理解，但只要您没有任何特殊要求，它也会使它不适合许多自动化问题。另一方面，Gradle是在充分授权和负责任的用户的基础上构建的

2、性能

缩短构建时间是最快速发货的最直接方式之一。Gradle和Maven都采用某种形式的并行项目构建和并行依赖性解析。最大的区别是Gradle的工作避免和增量机制。使Gradle比Maven快得多的前3个功能是：

增量 - Gradle通过跟踪任务的输入和输出并仅运行必要的操作来避免工作，并且只处理在可能的情况下更改的文件。
构建缓存 - 使用相同的输入（包括计算机之间）重用任何其他Gradle构建的构建输出。
Gradle守护进程 - 一种长期存在的进程，可将构建信息保持在内存中“热”。

在Gradle与Maven性能比较中，这些和更多性能特性使Gradle在几乎每种情况下的速度至少快两倍（使用构建缓存的大型构建速度快100倍）

3、用户体验

Maven的任期较长意味着它通过IDE的支持对许多用户来说更好。但是，Gradle的IDE支持继续快速提升。例如，Gradle现在有一个基于Kotlin的DSL，可以提供更好的IDE体验。Gradle团队正在与IDE制造商合作，以更好地提供编辑支持 - 敬请关注更新。

虽然IDE很重要，但是大量用户更喜欢通过命令行界面执行构建操作。Gradle提供了一个现代CLI，具有可发现功能，如“gradle tasks”，以及改进的日志记录和命令行完成。

最后，Gradle提供了一个基于Web的交互式UI，用于调试和优化构建：构建扫描。这些也可以在本地托管，以允许组织收集构建历史记录并进行趋势分析，比较构建以进行调试或优化构建时间。

4、依赖管理

两个构建系统都提供了内置功能，可以解析来自可配置存储库的依赖关系。两者都能够在本地缓存依赖项并并行下载它们。

作为库使用者，Maven允许覆盖依赖项，但仅限于版本。Gradle提供可自定义的依赖项选择和替换规则，可以声明一次并在项目范围内处理不需要的依赖项。此替换机制使Gradle能够一起构建多个源项目以创建复合构建。

Maven具有很少的内置依赖范围，它们在常见场景中强制使用笨拙的模块架构，例如使用测试夹具或代码生成。例如，单元测试和集成测试之间没有分离。Gradle允许自定义依赖项范围，从而提供更好的建模和更快的构建。

作为库生产者，Gradle允许生产者声明`api`和`implementation`依赖关系，以防止不需要的库泄漏到消费者的类路径中。Maven允许发布者通过可选的依赖项提供

总的来说，Gradle和Maven都是项目自动构建工具，编译源代码只是整个过程的一个方面，更重要的是，你要把你的软件发布到生产环境中来产生商业价值，所以，你要运行测试，构建分布、分析代码质量、甚至为不同目标环境提供不同版本，然后部署。整个过程进行自动化操作是很有必要的。

整个过程可以分成以下几个步骤：
编译源代码
运行单元测试和集成测试
执行静态代码分析、生成分析报告
创建发布版本
部署到目标环境
部署传递过程
执行冒烟测试和自动功能测试
如果你手工去执行每一个步骤无疑效率比较低而且容易出错，有了自动化构建你只需要自定义你的构建逻辑，剩下的事情交给工具去完成。

虽然两者都是项目工具，但是maven现在已经是行业标准，Gradle是后起之秀，很多人对他的了解都是从android studio中得到的，Gradle抛弃了Maven的基于XML的繁琐配置，众所周知XML的阅读体验比较差，对于机器来说虽然容易识别，但毕竟是由人去维护的。取而代之的是Gradle采用了领域特定语言Groovy的配置，大大简化了构建代码的行数，比如在Maven中你要引入一个依赖：

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

然后我将其转换成Gradle脚本，结果是惊人的：
dependencies {
compile('org.springframework:spring-core:2.5.6')
compile('org.springframework:spring-beans:2.5.6')
compile('org.springframework:spring-context:2.5.6')
compile('com.google.code.kaptcha:kaptcha:2.3:jdk15')
testCompile('junit:junit:4.7')
}

注意配置从原来的28行缩减至7行！这还不算我省略的一些父POM配置。依赖的groupId、artifactId、 version，scope甚至是classfier，一点都不少。较之于Maven或者Ant的XML配置脚本，Gradle使用的Grovvy脚本杀伤力太大了，爱美之心，人皆有之，相比于七旬老妇松松垮垮的皱纹，大家肯定都喜欢少女紧致的脸蛋，XML就是那老妇的皱纹。

Gradle给我最大的有点是两点。其一是简洁，基于Groovy的紧凑脚本实在让人爱不释手，在表述意图方面也没有什么不清晰的地方。其二是灵活，各种在Maven中难以下手的事情，在Gradle就是小菜一碟，比如修改现有的构建生命周期，几行配置就完成了，同样的事情，在Maven中你必须编写一个插件，那对于一个刚入门的用户来说，没个一两天几乎是不可能完成的任务

why：

git做版本控制，无论是否使用maven都行。
maven用来构建，可以通过添加maven repository（Maven仓库）中的依赖，减少项目中的jar数量，并且大的项目中模块交叉引用也能够用它很好地解决。
两者配合的方式，通过.gitignore文件中添加jar、target目录，可以避免将这些二进制文件、自动生成的文件加入到版本库中，从而减小版本库的大小，缩短同步时间。其他人同步之后，只需要执行maven命令，就能够自动从repo里面下载依赖，按照依赖树自底而上构建内部交叉依赖。
简单来说，maven让git不需要同步不必要的第三方库和自动生成的class、jar文件，并可以额外同步项目jdk版本等项目设置，标准化构建流程；git只是一个CVS工具，换成SVN、Mercurial也都可以。

但是，Maven有以下优点，

Maven是一个构建工具,服务与构建.使用Maven配置好项目后,输入简单的命令,如:mvn clean install,Maven会帮我们处理那些繁琐的任务.
Maven是跨平台的.
Maven最大化的消除了构建的重复.
Maven可以帮助我们标准化构建过程.所有的项目都是简单一致的,简化了学习成本.
总之,Maven作为一个构建工具,不仅帮我们自动化构建,还能抽象构建过程,提供构建任务实现.他跨平台,对外提供一致的操作接口,这一切足以使他成为优秀的,流行的构建工具.
但是Maven不仅是构建工具,他还是一个依赖管理工具和项目信息管理工具.他还提供了中央仓库,能帮我们自动下载构件.

Gradle和Maven都是项目自动构建工具，编译源代码只是整个过程的一个方面，更重要的是，你要把你的软件发布到生产环境中来产生商业价值，所以，你要运行测试，构建分布、分析代码质量、甚至为不同目标环境提供不同版本，然后部署。整个过程进行自动化操作是很有必要的。

整个过程可以分成以下几个步骤：
编译源代码
运行单元测试和集成测试
执行静态代码分析、生成分析报告
创建发布版本
部署到目标环境
部署传递过程
执行冒烟测试和自动功能测试
如果你手工去执行每一个步骤无疑效率比较低而且容易出错，有了自动化构建你只需要自定义你的构建逻辑，剩下的事情交给工具去完成。

虽然两者都是项目工具，但是maven现在已经是行业标准，Gradle是后起之秀，很多人对他的了解都是从android studio中得到的，Gradle抛弃了Maven的基于XML的繁琐配置，众所周知XML的阅读体验比较差，对于机器来说虽然容易识别，但毕竟是由人去维护的。取而代之的是Gradle采用了领域特定语言Groovy的配置，大大简化了构建代码的行数，比如在Maven中你要引入一个依赖：

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

然后我将其转换成Gradle脚本，结果是惊人的：
dependencies {
compile('org.springframework:spring-core:2.5.6')
compile('org.springframework:spring-beans:2.5.6')
compile('org.springframework:spring-context:2.5.6')
compile('com.google.code.kaptcha:kaptcha:2.3:jdk15')
testCompile('junit:junit:4.7')
}

注意配置从原来的28行缩减至7行！这还不算我省略的一些父POM配置。依赖的groupId、artifactId、 version，scope甚至是classfier，一点都不少。较之于Maven或者Ant的XML配置脚本，Gradle使用的Grovvy脚本杀伤力太大了，爱美之心，人皆有之，相比于七旬老妇松松垮垮的皱纹，大家肯定都喜欢少女紧致的脸蛋，XML就是那老妇的皱纹。

Gradle给我最大的有点是两点。其一是简洁，基于Groovy的紧凑脚本实在让人爱不释手，在表述意图方面也没有什么不清晰的地方。其二是灵活，各种在Maven中难以下手的事情，在Gradle就是小菜一碟，比如修改现有的构建生命周期，几行配置就完成了，同样的事情，在Maven中你必须编写一个插件，那对于一个刚入门的用户来说，没个一两天几乎是不可能完成的任务

翻版必究！