Build tool

2019/03/05 15:42
阅读数 20

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

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
在线直播报名
返回顶部
顶部