Gradle与Maven之构建生命周期

同样作为构建工具，Gradle相对于Maven的立意区别就在这生命周期的阶段上，Gradle将构建并行化（至少立意上是这样的，至于是否完全实现，还待后续版本不断完善），而Maven是将构建那些事儿全部串在了固定化的构建生命阶段串上了。

Gradle的构建生命周期只有三个阶段：初始化、配置和执行阶段。初始化相对于Gradle的另外两个概念项目和任务来说的，初始化阶段是组装项目和任务对象的，这很好理解，因为Groovy是面向对象的解释型语言，若要执行，必有对象。如此可以说初始化是超然构建之外的一个阶段。真正执行构建的任务，只有配置和执行阶段。每个任务都有配置和执行两个阶段，同时当构建进入配置阶段时，每个任务的配置将被执行；当构建进入执行阶段时，将执行包含的所有任务的执行阶段代码。

Maven的构建生命周期是內建的，或者说构建的所有阶段是固定的，排序也是固定的，并且是串行的。执行一次构建，也就是从构建生命周期串上走一次。

本人毕业那会学校里基本上都是C语言当道。C语言没有标准规范，因此整个开发过程，只需要编译生产可自行文件就大功告成。将编译等同于构建这样的观念占据了我整个职业生涯。Java语言流行后，我依然下意识任务构建的全部还是编译，甚至一度嫌弃jar文件有那么多花花肠子，感到莫名其妙。Maven工具出现在我的视野里后，总算在概念上认识到构建不仅仅包含编译，文档、源码打包、版本管理、测试、部署等等其他所有的一切都是属于构建这件事之内的。实践这个过程花费了我很多精力，特别是转换观念对我来说，新鲜又痛苦。

如今Gradle已经进入3.+版本了，我依然有一种错觉，仍然无法下意识认为编译之外的事儿对于软件来说有多么重要，需要花费这么大的精力去打造Maven或者Gradle这样的工具来支撑构建这件事儿。

反思的结论是，我们对待软件没有工程的觉悟，软件是一项工程，必定由各个环节组成，每个环节既然存在就十分必要，事无巨细都在工程之中。我们怠慢其它而只重编译，学校的教学观念给我们的影响巨大。最近不时会招聘一些刚毕业的学生，常常趁机问问他们的大学阶段的课程设计，似乎没有太大变化，C或C++仍然是启蒙语言，Java这些大部分仍然是选修课范围。我想说，观念的转变，在于细节，利益驱动的反应要快。观念滞后，毁的是一代人或更多。

若我们不把软件的构建当作一件工程来看，就不会去想构建什么的工具来辅助。Gradle这样的开源项目，既然不理解，就更谈不上如何参与其中。

网上找了两张图，或许可以简单示意一下：

Gradle的任务就像这个风铃，是竖着串起来的



Maven的任务就像这辣椒串，横着一条线串起来