Java的世界就是这么复杂。。。
很久很久以前写过一个Ant的任务xml。异常痛苦。这件天花了点时间了解Maven。下面的结论应该是有些偏颇和过时。不过，了解一个以前不知道的实物总是这样的。
Maven解决的几个痛点
- 包依赖：搜索包还是得去官网，搜到后再讲对应的xml粘贴到pom.xml中
- 构建：直接mvn package就可以打包了
- 工程结构：约定好了工程结构。但是为啥没找到自动生成工程结构的工具？
- 包发布：可以mvn install到local repository。不知道发布到Centeral Repo是否会比较方便。就冲官方Centeral Repo，感觉不会很方便的。。
- pom可继承，公司级别写一个base的，然后项目继承之
- 各种插件。不过也带来心痛点
Maven带来的新痛点
- Maven本身带来了很大的学习成本。在Amazon就可以搜到好几本专门讲Maven的书。我去，一个包管理得看一本书。。一如既往地很Java很复杂。
- pom.xml基于xml本身就把事情弄复杂了。很多pom的xml标签需要熟悉。很多坑需要踩。
- pom.xml手写。。eclipse有基于form的pom编辑器，但我不想安装eclipse。。mvn提供生成pom.xml的命令行参数，但，太tm长了。也没有找到方便的生成、操作pom.xml的工具。
- 干啥都要插件。。生成一个MANIFEST也要用插件
现在有了Gradle。知道Gradle还是在看Android工程时看到的。
Java强类型注定了它的工程配置文件只能用别的语言来描述。总不能用Java来描述吧。那么就用Java世界的标配xml来描述好了。于是就有ant.xml和pom.xml。xml虽然可以描述一切。对于逻辑描述真实捉襟见肘。于是就有人用另一个JVM语言来描述，我想为啥不用jruby呢？嗯，我熟悉，所以我希望是用jruby，学习成本减少很多。可是，Gradle是基于Groovy的。Groovy本来是要作为服务端语言被发明的。但是作者都说了，早知道有人发明了Scala，我就不发明Groovy了。现在Gradle把它捡起来，用来做自动化构建。还成立了Gradle. Inc！这让我想起了npm, inc。歪果仁为一个包管理工具和自动构建工具分别成立了一个公司！我觉得这里面应该有很多我不了解的东西。。
好了Gradle来了（其实很早以前就来了。。）
基于JVM动态语言的构建描述DSL。表达力比XML强太多。它试图集合Ant和Maven的优点，并解决它们的痛点。
好吧，我还没有开始了解Gradle。因为我还得学一下Groovy。。。可能使用Gradle并不需要学习Groovy，只需会使用对应的DSL就好了。也可能Groovy很好学，花一天时间就能学会。
我找到的资料都好老啊。我怀疑是我搜索的姿势不对。。
参考：
2014:The Ultimate Java Build Tool Comparison: Gradle, Maven, Ant + Ivy
2009:We’re Used to the Axe Grinding
