Question

前言： 接上一篇《小李的 Build 之路（上）》

小李发明的 ANT 确实是好用， 现在不仅仅是小李的公司， 连其他公司的朋友听说了，也拿去使用， 交口称赞。

只是小李发现了一点奇怪的现象，每个人在开始写新项目的 Ant build 文件之前， 都会找到自己说： “小李， 把你那个 build.xml 文件发我一份吧， 让我参考下。”

小李的那一份 build.xml 其实是自己项目的第一个 ant 脚本， 为啥大家都要把它

Copy 走呢? 刚开始的时候小李以为大家不会写，要按照自己的模板照葫芦画瓢。

偶然有一次，小李看到了别人项目的 Ant build 脚本， 不由得大吃一惊， 这简直和自己原始的 build.xml 如出一辙。

小李赶紧把公司内所有项目的 Ant 脚本都要过来，仔细观察了一下， 很快就发现了这些脚本中蕴藏着一些共同的“模式”，这些模式主要体现在 Build 的步骤上：

1. 从版本控制系统下载代码 2. 编译 java 文件，形成 jar 包 3. 运行单元测试 4. 生成代码覆盖度报告和测试报告 4. 打包形成 war 文件 5. 上传到测试服务器上，进行安装

其实这也难怪，实际的 Build 不就是这样的嘛。 但是中间也有不同之处：

(1) 路径不同，例如 java 源文件 下载下来以后放的位置不同，五花八门 编译成的 java class 放置的位置不同 测试报告放置不同 war 包生成后放置的路径不同 。。。 (2) 项目依赖不同，例如 各个项目依赖的第三方 jar 包可能是不一样的 各个项目都有一个 Web 子项目，它依赖于其他 java 项目，所以在 build 的时候，要先 build 这些 java 项目才行 例如下图中的 OnlineShop,这是个 Web 项目， 它依赖于 ApplicationConfg, LoggingFramework, OnlineShopApi 这三个子项目。

项目依赖这个没办法， 毕竟是各个项目的业务所要求的，小李没有办法改变。

但是那些不同的路径真的是必要的吗？ 能不能让大家的路径都保持一致呢 ？

一个新的主意像闪电一样划过黑暗的夜空： 确实可以保持一致， 但是大家都要遵循一定的约定 如果大家都这么做，小李就可以增强一下 Ant，只要运行 ant complie , 就会 自动 的去 src/main/java 找到源文件进行编译， 只要运行 ant test, 就会 自动 去 src/test/java 找到测试用例， 编译并运行。

换句话说， 只要遵循目录的约定， 大家就不用费心费力的指定各种路径了， 一切在背后由工具自动搞定， 这样的话 Build 脚本就可以极大的简化了 ，只需要寥寥几行即可。

这只是一个 java 项目，要是多个 java 项目，有依赖关系，像上面提到的 OnlineShop 依赖 OnlineShopAPI, AppplicationConfig, LoggingFramework , 该怎么处理？

这也不难， 小李想， 首先每个 java 项目都得遵守上述约定，其次需要定义项目之间的依赖关系， 也可以用 XML 描述出来。

每个 java 项目都需要有个叫 pom.xml 的文件， 例如 OnlineShop 这个项目的 pom 如下：

这样以来工具就能自动找到被依赖的项目， 然后去编译打包它了。

此外，各个 java 项目之间也需要按约定来组织目录，例如： +- pom.xml +- online-shop-web | +- pom.xml | +- src | +- main | +- webapp +- online-shop-api | +- pom.xml | +- src | +- main | +- java +- logging-framework | +- pom.xml | +- src | +- main | +- java +- app-config | +- pom.xml | +- src | +- main | +- java

如果扩展一下， 把第三方的 jar 文件例如 JUnit 也可以给用这种方式来描述： 想到这一层，小李不禁激动起来，因为第三方的 jar 管理一直是一个令人头疼的问题，最早的时候大家都是手工的 Copy 来 Copy 去， 由于版本不同导致的错误特别难于发现。

每个人在建立自己 Eclipse workspace 的时候， 得拿到所有依赖的 jar 包， 并且在项目上设置好， 可是非常的费劲啊。

如果利用这种 声明的办法 ， 每个人岂不卸下了一个巨大的包袱 ？　

当然公司需要建立一个公用的第三方 jar 文件版本库， 把公司最常用的第三方 jar 包都放进去， 工具在分析项目的配置文件 pom.xml 的时候，就可以去公司的版本库里去读取并且下载到本地。

将来有新人进入公司， 只要给他一个 pom.xml ， 用 Eclipse 导入，就能轻松的把一个可以直接运行的 workspace 建立起来， 再也不需要设置那些烦心的 jar 了。

如果将来在网络上建立公开的软件版本库， 任何人都可以从那里去下载各种软件包，那受惠的可不仅仅是自己公司了， 而是所有人，真是一个激动人心的场景啊。

不过还是从自己公司开始吧， 小李冷静下来分析了一下： 让所有的项目组都使用约定的目录，并且建立一个公司级别的软件库，自己可是没有这样的权限啊， 小李去找 CTO 老张求助。

老张不愧是老江湖， 听了几分钟小李的介绍，马上就明白了， 并且把这个想法提升了一个高度：

“你这叫 约定重于配置 ， 知道不？ 从 Ruby on Rails 开始，这个词开始流行了， 大家现在都很忙， Ant build 脚本用的也没问题，先不改了”

小李还不死心： “可是这么做的话对以后的新项目大有好处啊，不用 Copy 繁琐的 build 脚本了， 也不用费心的折腾 workspace 了”

“那也不能现在改，项目进度最重要，大家都没时间， 这样吧，等大家项目闲下来再改动如何？ ” 老张妥协了一下。

可是在公司基本上就不会有空闲的时间， 一个个新需求压的大家透不过气来，偶尔有空闲时间，大家也都犯懒了， 总是想休息。

此外惯性的力量是惊人的，大家都愿意待在舒适区里， 不愿意变化， 虽然也看到了新工具的好处， 大家都懒得换新的。

时间过的很快，一年过去了， 小李看着自己辛辛苦苦加班写出来的 Ant 2.0 , 还是无人采用， 很是伤心。

经过公司的允许， 小李决定把这个工具开源， 为了和 Ant 区分开来， 特地起了个新的名称： Maven。

Maven 迅速被大家用了起来，除了小李的公司。

又过了半年， 小李跳槽了。

---

即日起，您只需免费接入 DaoVoice，即有机会赢取大疆无人机、XBox 等惊喜大礼！

DaoVoice 是一款革命性的应用运营平台，融合了「在线聊天」、「客服支持」、「用户画像」、「行为引导」等功能为一体， 按需获取用户信息和行为，实现场景化消息推送，让通知更富有人情味。

点击“ 阅读原文 ”，了解更多活动详情。