架设私有Maven仓库

Martin的文章并没有涉及到依赖管理的内容，但在Java的世界中，依赖管理是开发人员不得不面对的问题。无论是外部的开源类库依赖，还是项目内部的模块间依赖，都需要有效地管理。可以说依赖管理是持续集成核心的内容之一。Maven通过其依赖管理机制和随处可用的中央仓库有效地解决了这个问题，用户只需要在POM中声明项目所需要的依赖，Maven就能在构建的时候自动从仓库解析依赖。

不过仅仅这样是不够的，我们知道，持续集成的最大好处在于降低风险，简单地来说就是尽早暴露问题，能让开发人员及早发现并修复，从而降低修复成本。可是，如果每个人都从中央仓库重复下载依赖，这是非常耗时的，集成的反馈周期肯定会延长。我已经无数次听到有人抱怨“Maven在下载整个Internet！”。构建要快！持续集成反馈要快！Maven你不能拖慢这个流程。

幸运的是开源世界有很好的解决方案，只要使用Maven仓库管理器软件如Nexus建立一个私有的Maven仓库，问题就能迎刃而解。原理很简单，这个位于局域网内的Maven仓库能够代理所有外部仓库，从而避免所有人从Internet重复下载依赖文件。这样Maven解析依赖的时候仅限于局域网，构建速度就大大地加快了。例如大家都需要使用junit-4.8.2.jar，当第一个人向私有仓库请求的时候，私有仓库从中央库下载并缓存下来，假设耗时10s，之后其他人需要junit-4.8.2.jar的时候，私有仓库直接使用缓存的文件，这个耗时可能就是1s。如果有100个开发人员使用该文件，那节省的时间就是 100 * 10 - ( 10 + 99 * 1 ) = 891s ，实际情况中依赖的数量可能会是成百上千，那节省的时间就变得非常的可观。

也许有人会说，我也完全可以将项目依赖加入到版本控制中，这一点甚至在《卓有成效的程序员》中都被明确提及，在该书第5章的"DRY版本控制"一节中，Neal Ford有这么一段话：“所有用来构建项目的东西都应该被放入版本控制，包括二进制文件（类库，框架，JAR文件，构建脚本等等）”。作者进一步解释了其目的，这么做能够保证项目不受外部因素影响（如依赖版本变化，甚至丢失），保证构建的稳定，作者也同时提及了一般版本控制工具处理二进制文件的性能问题。抛开这条结论性的实践，仔细考虑其目的，我们就能发现，私有Maven仓库同样能保证构建的稳定，而且能避免版本控制工具处理二进制文件而造成的潜在性能问题。所以，我斗胆说一句，Neal Ford所提的这条实践OUT了！

私有Maven的仓库的意义还不仅限于此，结合自动化部署和Maven的SNAPSHOT机制，它能大大促进项目集成的效率。

在模块化的开发环境中，大家各司其职，专注于自己所负责的模块，持续集成的规则是，在往版本控制提交代码前，需要先保证本地构建没有问题，那一般的做法就是更新所有模块的代码并构建。可是，真的需要构建那些其实你并不怎么关心的模块么？且不谈一旦构建他人代码时出错，你往往会不知所措，这种做法同时也增加了本地构建的时间。

Maven有SNAPSHOT版本的概念，其目的就是让你能够构建一个临时的版本，供团队他人使用，这样他们就不必在代码的层次关心自己的依赖。于是私有Maven仓库就充当了一个中介的作用，而持续集成服务器就多了一个职责，每次它成功构建一个模块，都应该将该模块的SNAPSHOT版本发布到Maven仓库中。现在，大家就不用去构建别人的代码了，Maven能自动帮你从私有仓库解析下载依赖的最新SNAPSHOT（使用mvn命令的-U参数强制更新）。注意，除了持续集成服务器外，任何其他人都不应该发布SNAPSHOT版本到Maven仓库，因为只有持续集成服务器的环境是可信任的，你能在本地成功执行mvn clean install并不代表持续集成服务器上该命令能成功，由于每个人的本地环境各有差异，因此集成的成功与否应当以持续集成服务器为准，而只有集成成功后，SNAPSHOT才可以被部署到私有仓库供他人使用。

鉴于上述的原因分析，我认为在基于Maven的持续集成环境中，再怎么强调私有Maven仓库的重要性都是不为过的。

那个我其实验旧的差不多了,可以代理maven中央仓库的jar包.
但是 你搞了那个dubbo的demo-provider以及它所依赖的jar包在maven中央仓库没有,所以代理不了. 后台我去掉那个换了个zk_client的jar包就可以实现私服了.

不知道为什么nexus代理不了淘宝的maven仓库,建立不了nexus索引...

附一个demo就更好了...