第一个轮子
前几天我们在公司内部开始造轮子，启动了一个内部项目，旨在为公司内部其他所有项目组提供服务。将欲取之，必先予之，既然想被服务，首先就要接入，于是要求其他项目在工程中集成我们的agent，对于maven项目来说，也就是在pom中加入我们的依赖。因为是内部项目，度尽劫波兄弟在,相逢一笑泯恩仇，大家也就勇往直前的使用了我们的snapshot版本。
第二个轮子
结果一个项目组构建完war文件之后，把war文件扔到服务器上执行，结果容器启动失败，说某某class not found，查看了一下，是我们的agent初始化失败了。为了不影响他们的正常业务，紧急把我们的agent从pom中去掉后发布了。为什么好好的class在服务器上就无影无踪了呢？把持续集成上归档的war包下载下来一看，里面少了好几个jar包，这些jar包和我们agent唇齿相依，相依为命，怎么就夫妻本是同林鸟，大难临头各自飞了呢？看了一下持续集成的日志，里面有一个warning，说
The POM for xxx is invalid, transitive dependencies (if any) will not be available
看完这个warning，大家面面相觑，本地都好好的，怎么突然就invalid了？变节也太快了吧？说来也巧，这个持续集成是公司的另一个轮子，于是顺理成章的成了替罪羊，大家一致认为，应该就是这个持续集成有问题，不能自动更新snapshot依赖，每次清理一下本地maven库就行了。
第三个轮子
然而福无双至，祸不单行，过了两天，另一个项目组也有同样的问题。打包成功，放到服务器上又报错，关键这次他们用的是老牌的持续集成工具Jenkins，不是公司的那个替罪羊，这下无法自圆其说了，真是尴尬啊。
这充分说明问题不是持续集成的，又排除了maven的问题之后，最后发现是公司的私服有问题。真是无巧不成书，这个私服也是公司的轮子。公司私服的坑人之处在于，它默认所有的库都是release版本，而且没有改成snapshot的机会。
对开源软件的恨铁不成钢
痛定思痛的想一下，感觉有些开源软件设计思路真有问题。
对maven来说，你发现了pom是invalid，并且还排除了传递依赖，你有什么自信认为这种情况下build出来的东西就是用户想要的？正确的思路不应该是直接build失败么？
对公司私服背后的未知名开源软件来说，用户向release类型的仓库中deploy snapshot版本的构建，你不是应该直接拒绝么？
正所谓，千里之堤毁于蚁穴，千里之行始于足下，早点发现问题才能让用户痛改前非，不至于在错误的道路上越走越远啊。
后记
我已经给maven提了issue，相信以后就没有这个问题了。
至于公司的私服，应该用的不是nexus，因为nexus是无法向release类型的仓库deploy snapshot版本的。