使用仓库管理器——Sonatype Nexus的九大理由

（译自：Nine Reasons to Use a Repository Manager: Sonatype Nexus ）

 

 

目前有很多组织使用了一些工具依赖于Maven仓库，但他们并没有采用一个仓库管理器，对于这一点我十分惊讶。可能没人提出来这一点，没人站出来告诉别人使用一个仓库管理器能带来什么好处。我经常能从很多不使用Maven仓库管理器的组织那里听到这样的字眼：“我们不需要那么复杂……”，或者“中央仓库够了，我们不需要在本地建立这样一个仓库”

 

不用说，关于什么“是”一个好的Maven仓库，还存在很多误解。首先，安装它一点都不复杂。你只需要花几分钟就能下载并安装好Nexus ，而且我们已经特意的使得这一过程变得容易，并且尽可能减少侵入性。第二，一个缓存远程仓库的仓库管理器并不会缓存所有的东西。一个好的仓库管理器只会按需的缓存内容。这里是为那些排斥仓库管理器的人提供的九条理由。

 

九 - 加速构建

当你在Maven中运行多模块项目构建的时候，你认为Maven是怎么知道它是否需要更新插件或者snapshot依赖的呢？它需要为所有需要检验的构件向服务器提出一个请求。即使没什么变化，如果你的项目依赖于一些SNAPSHO或者你没有指定插件版本，Maven就必须对远程仓库提交数十至数百的请求。所有这些通过公共Internet的请求加起来会浪费很多时间。我看到过一个复杂的构建，在安装了本地Nexus之后，节省了75%的时间。不要再浪费编码时间去无畏的等待Maven对远程仓库的请求了。

 

八 - 节省你自己的带宽

组织越大，节省带宽就越重要。如果你有数千开发者不停的浪费带宽在下载同样的文件，那么使用一个仓库管理器可以保存一个本地的缓存，从而节省大量的带宽。即使一些小型的组织，对于网络连接和IT运行的预算也有限，也必须处理很多开发人员浪费带宽不停重复下载同样文件的问题。

 

七 - 节省中央Maven仓库的带宽

这可以说是一种公德心，利己利人。运行一个中央Maven仓库不容易。基于全球软件构件的需要，服务数百万的请求，数T的数据，一点都不便宜。简单的事情如每个组织安装一个本地仓库管理器可以大量降低对中央仓库的带宽需求（至少一半）。如果你有大于两个开发者在使用Maven，那么请为了中央仓库义务的安装一个仓库管理器。

 

六 - 可预见性和稳定性

过去一些年，你多久会遇到一次由于断网引起的业务彻底中断？让每天的工作依赖于中央仓库意味着你正依赖于因特网连接（事实上中央仓库是24/7可用的）。虽然我们有信心保持中央仓库24/7运行，但你还是应该花一点时间建立你自己的仓库，以确保你的开发团队不会由于任意一方的网络中断而惊讶。如果你有本地的仓库管理器，如Nexus，你可以确保即使你失去了网络连接你还能工作。

 

五 - 控制和审计

当然，你已经转移到了Maven（或者Ivy，Ivy读取同样的仓库），而且你有一房间的开发人员，他们被授权添加或者删除依赖，以及试验新的框架。我们都清楚。开发人员可能都对试验新框架更感兴趣，而不是正常工作。但不幸的是，很多时间，一个架构师，或者一个架构小组需要建立组织使用的基线标准。Nexus提供这一层次的控制。

 

如果你需要对那些组织中使用的构件进行更多的监管，看一下Nexus。没有仓库管理器，对于那些你开发团队会使用的依赖你只有很少的控制。

 

四 - 能够部署第三方构件

你希望能够基于开源数据库工作，如MySQL或者Postgres，但是你组织有不同的需求，和Oracle有一个长期的支持合同。因此，你有一系列JAR文件不能够从公共Maven仓库获得。你需要将这些构件部署到仓库中，然后配置Maven去读取该仓库。

 

你不用为此手工编写一些POM，只要下载Nexus，然后花两三分钟时间使用这个免费，功能强大的工具来创建一个仓库，部署第三方构件。Nexus提供了直观的上传界面，你可以使用它上传任意JAR文件，然后在你项目依赖中引用它。

 

三 - 可以建立本地内部仓库

非常好，你正使用Maven，每个人都从头开始根据代码执行快速的构建。整个一年，这都工作得很好，但是当系统变得庞杂，程序员开始抱怨构建花了太多时间。你可以通过分割项目解决这个问题，然后使用Nexus作为一个内部仓库来存储内部的依赖。

 

例如，有一个公司有30个开发者，被分成三个10人的小组，每个小组关注于系统的不同部分。如果不能够很方便的实现内部依赖共享，类似的小组就不得不创建一个基于文件系统的仓库，或者将系统整个的构建，那样依赖就能被安装到每个开发者的本地仓库。

 

另一种选择是将项目分隔成不同的模块，每个模块都依赖于存储在Nexus仓库中的构件。这么做之后，小组之间可以通过基于Nexus交换已编译的snapshot和release构件来协作。换句话说，你不需要让没个开发者签出巨大的包含整个组织代码的多模块项目。组织中的每个小组可以发布snapshot构件至本地Nexus，从而每个小组可以维护一个只包含它负责代码的项目结构。

 

在宏观层次，公共Maven仓库及建立项目定义的严格制度，可以充当开源世界中跨项目协作的基础。（这听起来是不是很重要，很“令人敬畏”？）

 

二 - 可以建立公共仓库

如果是一个开源项目，或者你将软件发布到公共环境，Nexus可以是一个你用来为外部用户提供构件服务的工具。这么想……上你发布项目的一个版本是什么时候？假设它没被发布到Maven仓库中，你很可能需要编写一些脚本来打包此次发布的内容，可能某些特定的人需要使用一个超级权限的密钥来为该发布签名。然后，你必须将其上传到一些web服务器上，然后确保相应的页面被更新，正确描述了此次发布。这里有很多不必要的复杂度。

 

如果你正使用Nexus，它可以被配置成一个暴露在公共世界的宿主仓库，你就可以使用Maven的打包和装配能力，以及Maven仓库的结构，来使得一次发布变得非常的简单。而且，这不仅仅正对于JAR文件和Java web应用；Maven仓库可以存储任何种类的构件（事实上，我正考虑使用Maven仓库结构来发布用户文档和视频内容）。Nexus，及Maven仓库，总得来说为发布定义了大家都知道的结构。如果你正编写一些Java类库，将其发布到你自己的Nexus实例中，然后提供公共仓库服务，就可以让人们更容易的马上开始使用的的代码。

 

一 - 这相当简单

类似的事情我经常听到。有一个早晨的Scrum会议，或者项目状态的周会。一些低层的程序员怯懦的举起他的手说，“我们可以安装一个如Nexus的仓库软件么？我认为它能帮助我们显著的加速很多工作。”一直被时间的预算压着的开发经理，听到单词“安装”和“软件”，就马上否决了这件事情，理由是他们没有时间做这种基础工作，因为这不是“需求驱动”的。（我看到过这种事情发生。）

 

这个经理不知道的是，在一个共享的机器上安装Nexus，然后配置随后的系统服务可能是需要花不到十分钟的时间。事实上，你可以在免费的Maven书上读到安装说明。安装Nexus十分的简单。我已经有了一些实践，但是我认为任何一个知道如何操作web浏览器的人都可以在几分钟内完成这项工作。