Freewind @ Thoughtworks scala java javascript dart 工具 编程实践 月结 math python english [comments admin] [feed]

广告： 云梯：翻墙vpn (省10元) 土行孙：科研用户翻墙http proxy (有优惠)

项目需要，开始学习maven，今天花了一整天的时间，看完了《Maven实战》这本书。书是好书，看完之后，对maven整体有了较多的了解，也知道了在项目中怎么去使用，感觉收获很大。

我感觉maven这一套还是很严谨的，虽然繁杂，但是感觉很规范，各种情况它都考虑到了。而且跟Jenkins结合起来，也是很方便的。我想不到还有什么更好的办法可以解决它所要解决的问题。

突然想到：为什么我以前不喜欢用maven？为什么似乎人们也不喜欢maven呢？

我不喜欢是因为我以前没有掌握maven，看到那大堆的xml，总有种无法下手的感觉。而且在使用中时老是遇到问题，却很难在短时间内找到答案。总觉得它太笨重了。

今天看完书也证实了我之前的看法是正常的。maven设计了一套复杂的体系，比如库的坐标、依赖、生命周期、插件等，环环相扣，如果不把这一套东西都搞明白，是没法下手的。这种情况，跟angularjs很像，都是设计了一套相对封闭但又有特色的体系，虽然内部配合很好，但对于外界就没那么友好了。在花时间了解、适应、认同它之前，会经常撞墙的。

但为什么人们也不喜欢maven呢？应该有很多人对maven很熟悉的，但为什么他们还在寻找更好的工具呢？比如buildr，比如gradle?

今天带着疑问，我搜索了一些文章，大概明白了。

首先要提一下ant，ant与maven是两个极端。ant很灵活，如同瑞士军刀，但没有统一的流程，需要写很多的代码，且每个人都有自己的一套。而maven则相反，定义了严谨、繁琐的流程，考虑了很多，但具体到某一个任务的时候，又不够灵活。要么你去搜别人写好的插件，要么自己写，不论哪种方式，都会让人觉得束手束脚，感觉被maven设计出来的锁链绑着。一想到随便来点什么都要上插件，让人压力巨大。

看到thoughtworks以前有一篇讲maven的文章，提到说，对于构建工具，在plugin的层面上抽象，还是不够灵活。还是需要一种能语言层面上抽象的工具。比如buildr，比如gradle。（原文找不到了，这是我根据搜到的片断自己理解的）

而gradle正好填上了这两个极端的中间。它利用groovy提供的dsl，写起来要比xml舒服很多，而且可以直接如果函数调用般调用ant提供的工具，还可以直接写groovy(Java)代码。相比ant/maven，人们反映使用它的感觉要舒服多了。

希望这个项目有机会尝试一下gradle。

---

更新：

想不到这篇不太有营养的文章上了“tw好声音”。正好这几天在志恒同学的努力下，成功的把项目中的maven换成了gradle，所以赶紧上来补充两句。

首先关于maven，大家可以看看评论中杨博这篇霸气的文章：《如果我来设计Maven》，深度有营养。

然后讲讲项目的情况。

客户的项目是一个java项目，用maven管理。虽然代码不多，但是分成了好几个模块。在根目录下放一个总的POM.xml，然后每个子模块里一个POM.xml，包含在总POM里。这几个月我们一直在它的甚础上开发，对它进行了多次修补，感觉如下：

1. 运行慢。运行一次mvn clean test，差不多要五分钟时间，够上个厕所泡杯水再聊聊天了。而且每多一个模块，就会多出一截时间。
2. 日志乱。maven的日志真是超乱，非常难以阅读。每次出点问题想从日志里找线索，都是一场折磨
3. 文档难。遇到问题想从maven官网上找点资料，感觉很难。满屏幕都是文字，为什么看不到自己需要的？
4. 插件烦。P大的一点事也要加插件！比如，我们想建个跟src平级的integationTest目录，也要下插件！一堆配置！
5. 心情差。每次编辑POM、看到POM、甚至想到POM，都感觉压力巨大，直接影响写代码心情~

前些天终于要开始开始一个新模块了，志恒同学实在忍不住，喊出“风险我担！周末加班我也干！”的壮语后，花了两天时间，不仅在新模块里配好了gradle，还把之前多个maven模块也换好了，包括POM里调用的所有插件。在此向志恒同学致敬：）

现在的gradle脚本看起来舒服多了。代码简洁、结构清晰、配置简单，再配上它的吉祥色绿色，有种春风拂面的感觉：

1. gradle代码是由groovy写成的dsl，写起来有种json的感觉，简洁清晰，一句废话都很难找到。
2. 文档很好。由于gradle语法不像XML那样能提示，所以它的网站文档很好。清晰、解释清楚，示例丰富，很有帮助
3. 插件丰富。gradle内置了对ant任务的支持，表示各种ant任务你都可以直接拿过来用。并且在gradle里，可以用一种很简洁的语法去调用它们，像调用函数一般
4. 功能强大。gradle代码实际上就是groovy代码，所以可以方便地嵌入groovy代码。你既可以在里面加个println "hello"什么的帮助调试，又能写一些较复杂的groovy代码实现一些复杂的功能。既强大，又灵活。如果需要，不要怕学习另一门语言，因为比起你“精通maven”所花费的时间精力可要少多了。

由于项目保密的原因，不方便贴出实际代码，不过在网上应该可以搜到很多maven与gradle代码的对比例子。我个人感觉因为有了gradle，groovy终于有了一个杀手级的项目。

等在项目中有更多的gradle使用经验时，再来更新。

一些评论

Ivolianer

1. pom.xml 太繁复
   不论用何种表现形式，关键的就是，公司名、项目名和版本号。
   用 Gradle 能少打包名？ 好吧，也许看着顺眼。

2. 依赖冲突
   Maven 最大的问题应该就是个。
   虽然 Maven 有最近原则和第一生命原则来解决依赖冲突，但实际还是有问题。
   不过，既然 Gradle 用的还是 Maven 的仓库，那它在这方面有何建树？

3. 本地Jar依赖
   某个版本的Maven不能引用本地架包，但现在可以用个 system scope 引入了。

在考虑用 gradle ，但觉得优点不大。

杨博

http://www.ac.net.blog.163.com/blog/static/13649056201111793412935/

如果你的项目用到的所有底层技术都不用自己开发，都是“成熟解决方案”，那么Maven挺适合的。

不过，任何软件存在的意义，就是为了解决前人没有解决的问题。

如果你只用“成熟解决方案”，那么你的软件必定毫无存在的意义