为什么选择Gradle

如果你曾经使用过构建工具,你可能会对遇到的问题感到很沮丧,构建工具不是应该自动帮你完成项目的构建吗?你不得不向性能、扩展性等妥协。

比如你在构建一个项目的发布版本时,你要把一个文件拷贝到指定的位置,你在项目的元数据那里添加了版本的描述,如果版本号匹配一个特定的数字时,就把文件从A拷贝到B处。如果你依赖XML来构建,你要实现这个任务就像噩梦一样,你只能通过非标准的机制来添加一些脚本到构建中,结果就是把XML和脚本混在一起,随着时间的推移,你会添加越来越多的自定义的代码,结果就是项目越来越复杂很难维护。为什么不考虑用表达式的语言来定义你的构建逻辑呢?

另外一个例子,Maven跟随约定优于配置的规范,引入了标准化的项目布局和构建生命周期,给很多项目确保一个统一的结构这是个不错的方法。然而你手上的项目刚好和传统的约定不一样。Maven的一个严格的约定就是每个项目都要生成一个artifact,比如jar文件,但是你怎么从同一个源代码结构中创建两个不同的JAR文件,因此你不得不分开创建两个项目。

Java构建工具的发展

最早出现的是Ant,Ant里的每一个任务(target)都可以互相依赖,Ant的最大缺点就是依赖的外部库也要添加到版本控制系统中,因为Ant没有一个机制来把这些jar文件放在一个中央库里面,结果就是不断的拷贝和粘贴代码。

随后Maven在2004年出现了,Maven引入了标准的项目和路径结构,还有依赖管理,不幸的是自定义的逻辑很难实现,唯一的方法就是引入插件。

随后Ant通过Apache Ivy引入依赖管理来跟上Maven的脚步,Ant和Ivy集成实现了声明式的依赖,比如项目的编译和打包过程

Gradle的出现满足了很多现在构建工具的需求,Gradle提供了一个DSL(领域特定语言),一个约定优于配置的方法,还有更强大的依赖管理,Gradle使得我们可以抛弃XML的繁琐配置,引入动态语言Groovy来定义你的构建逻辑。


为什么要选择Gradle

假如你是一个开发者,项目自动构建是你每天工作的一部分,难道你就不想让你的构建代码和你写的源代码一样可以扩展、测试和维护?Gradle的构建脚本是声明式的、可读的,可以清晰的表达意图。使用Groovy代替XML来写代码大大减少了构建代码的大小。更重要的是,Gradle集成了其他构建工具,比如Ant和Maven,使得原来的项目很容易迁徙到Gradle。