首页 » Maven实战 » Maven实战全文在线阅读

《Maven实战》9.3.1 Nexus内置的仓库

关灯直达底部

在具体介绍每一种类型的仓库之前,先浏览一下Nexus内置的一些仓库。单击Nexus界面左边导航栏中的Repositories链接,就能在界面右边看到如图9-3所示的内容。

这个列表已经包含了所有类型的Nexus仓库。从中可以看到仓库有四种类型:group(仓库组)、hosted(宿主)、proxy(代理)和virtual(虚拟)。每个仓库的格式为maven2或者maven1。此外,仓库还有一个属性为Policy(策略),表示该仓库为发布(Release)版本仓库还是快照(Snapshot)版本仓库。最后两列的值为仓库的状态和路径。

下面解释一下各个仓库的用途。由于本书不涉及Maven 1的内容,maven1格式的仓库会被省略。此外,由于虚拟类型仓库的作用实际上是动态地将仓库内容格式转换,换言之也是为了服务maven1格式,因此也被省略。

图9-3 Nexus内置的仓库列表

·Maven Central:该仓库代理Maven中央仓库,其策略为Release,因此只会下载和缓存中央仓库中的发布版本构件。

·Releases:这是一个策略为Release的宿主类型仓库,用来部署组织内部的发布版本构件。

·Snapshots:这是一个策略为Snapshot的宿主类型仓库,用来部署组织内部的快照版本构件。

·3rd party:这是一个策略为Release的宿主类型仓库,用来部署无法从公共仓库获得的第三方发布版本构件。

·Apache Snapshots:这是一个策略为Snapshot的代理仓库,用来代理Apache Maven仓库的快照版本构件。

·Codehaus Snapshots:这是一个策略为Snapshot的代理仓库,用来代理Codehaus Maven仓库的快照版本构件。

·Google Code:这是一个策略为Release的代理仓库,用来代理Google Code Maven仓库的发布版本构件。

·java.net-Maven 2:这是一个策略为Release的代理仓库,用来代理java.net Maven仓库的发布版本构件。

·Public Repositories:该仓库组将上述所有策略为Release的仓库聚合并通过一致的地址提供服务。

·Public Snapshot Repositories:该仓库组将上述所有策略为Snapshot的仓库聚合并通过一致的地址提供服务。

举一个简单的例子。假设某公司建立了Maven项目X,公司内部建立了Nexus私服,为所有Maven项目提供服务。项目X依赖于很多流行的开源类库如JUnit等,这些构件都能从Maven中央仓库获得,因此Maven Central代理仓库会被用来代理中央仓库的内容,并在私服上缓存下来,X还依赖于某个Google Code的项目,其构件在中央仓库中不存在,只存在于Google Code的仓库中,因此上述列表中的Google Code代理仓库会被用来代理并缓存这样的构件。X还依赖于Oracle的JDBC驱动,由于版权的因素,该类库无法从公共仓库获得,因此公司管理员将其部署到3rd party宿主仓库中,供X使用。X的快照版本构件成功后,会被部署到Snapshots宿主仓库中,供其他项目使用。当X发布正式版本的时候,其构件会被部署到Release宿主仓库中。由于X用到了上述列表中的很多仓库,为每个仓库声明Maven配置又比较麻烦,因此可以直接使用仓库组Public Repositories和Public Snapshot Repositories,当X需要JUnit的时候,它直接从Public Repositories下载,Public Repositories会选择Maven Central提供实际的内容。