Build tool

what：

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

how：

一、灵活性

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

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

二、性能

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

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

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

三、用户体验

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

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

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

四、依赖管理

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

做为库使用者，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中你必须编写一个插件，那对于一个刚入门的用户来讲，没个一两天几乎是不可能完成的任务