pom to gradle

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

---

　　都是自动构建工具，但是完全是两个产品。Maven应该目前在Java企业级开发中占的比重比较大，Gradle是后起之秀，Google的Android Studio主推的就是Gradle。
　　Gralde吸收了Maven与Ant的优点，可以列举出很多。然而大量的实践与思考发现Maven相比于Gradle的不灵活，正是它的优点，避免了大量聪明的Build Engineer的出现。

---

　　1.面向未来，就目前的趋势而言，gradle或者maven正逐渐演化为一种标准。尤其是国际上。比如你去spring官网看demo，它们一般提供基于这两种的源码，还有android开发，很多流行的库，demo演示都是通过gradle搭建的，你不懂gradle就很难跟它们接轨。这显然是固步自封的表现。
2.极细的粒度，给你更大的发挥空间。你用eclipse的run的时候，你并不知道eclipse是怎么执行的，即便你知道，但是不可能轻易结合自己的代码逻辑。举个例子：我需要在run java项目的时候，把flex项目先编译好，放到web目录下。类似于这样，大部分情况下，光靠IDE自己的功能就力不从心了。 但是gradle给了你两个维度的机会，让你能干的更多。 第一 task的dependsOn、finalizedBy 让你可以把各种工作串行连接；第二 绝大多数插件是开源的，也就是用的不爽，你自己可以改，那样就更灵活了。当然这只是冰山一角。
3.协作，一个个build文件，描述项目依赖，插件，显然更具有一致性。再也不需要把那些讨厌的jar包提交到git了，要知道git里面存放二进制简直就是灾难。还有，甚至可以通过gradle跟，非程序员交流，比如你想让美工可以自己测试修改并在项目里面看最终效果。这时候你让她装个idea，估计她会很不情愿。但是，你可以通过gradle，告诉她，把素材覆盖到某某文件之后，只要在控制台来个gradle run，刷新页面就能看到效果了。（仅是个例子，可能不严谨）
4.布道groovy，gradle所使用的语言，也许groovy并不能算是jvm里的屠龙刀，但是也绝对可以算是一把锋利的匕首。相信我，作为一个java程序员，试着在代码中融入groovy，一定乐趣无限。尤其是还能用在android项目。