第六章 仓库

1.   Maven 在一个工作站上的某个位置统一存储所有 Maven 项目共享的构件，这个统一的位置就是仓库。 Maven 项目将不再各自存储其依赖的文件，它们只需要声明这些依赖项目的坐标，在需要的时候， Maven 会自动在仓库中找到它们，并使用它们。一个 Maven 项目构建完毕后生成的构件也可以安装到仓库中供其它项目使用。

 

2.   一个构件在仓库中的路径为：

 

groupId/artifactId/baseVersion/artifactId-version(-classifier).packaging 。其中 groupId 中的“ . ”会被替换成路径分隔符“ / ”， baseVersion 主要是对应 SNAPSHOT version 而言的，如果一个构建的 version 是 1.0.0-SNAPSHOT ，那 baseVersion 就是 1.0.0 。例如：

org.testing:testing:2.5.6-SNAPSHOT:jdk5:jar 就会对应到

org/testing/testing/2.5.6/testing-2.5.6-SNAPSHOT-jdk5.jar

 

3.   Maven 仓库分为两类：本地仓库和远程仓库。当 Maven 寻找构件时会先查找本地仓库，如果本地仓库不存在此构件，或者需要查看是否有更新的构件版本， Maven 就会去远程仓库查找。

 

4.   一些公共远程仓库： Java.net Maven 库（ http://download.java.net/maven/2 ）和 JBoss Maven 库（ http://repository.jboss.com/maven2/ ）。

 

5.   Maven 默认的本地仓库位置是在用户目录下的 .m2/repository 下。也可以修改 .m2/settings.xml 自定义仓库位置：

 

<settings>
  <localRespository>D:\java\repository</localRepository>
</settings>  

 

6.     mvn clean install 可以将当前 Maven 项目构建出的构件安装到本地的仓库中。

 

7.   Maven 默认自带了一个中央仓库，解压 lib/ maven-model-builder-3.0.jar （ Maven2 中为 maven-2.2.1-uber.jar ），然后访问路径 org/apache/maven/model/pom-4.0.0.xml （ Maven2 中为 org/apache/maven/project/pom-4.0.0.xml ），可以看到：

 

<repositories>

  <repository>

    <id>central</id>

    <name>Maven Repository Switchboard</name>

    <url>http://repo1.maven.org/maven2 </url>

    <layout>default</layout>

    <snapshots>

      <enabled>false</enabled>

    </snapshots>

  </repository>

</repositories>

 

Maven1 的 layout 是 legacy ，构件会有不同的文件路径。 snapshots 的 enabled 设为 false 表明 Maven 不会从该远程仓库下载 SNAPSHOT 版本的构件。

 

 

8.   私服是一种特殊的远程仓库，它可以：

    1） 节省外网带宽。（构件缓存在局域网的私服上）

    2） 加速 Maven 构建。（构建时只需检查私服上的更新）

    3） 部署第三方构件。（有些构件因版权问题不能放在公共仓库上）

    4） 提高稳定性，增强控制（ Internet 不稳定时不影响构建。 Nexus 有许多增强功能）

    5） 降低中央仓库的负荷

     

 

9.  可 以修改项目的 POM ，添加远程仓库的配置：

 

<repositories>

  <repository>

    <id>jboss</id>

    <name>JBoss Repository</name>

    <url>http://repository.jboss.com/maven2/</url >

    <releases>

        <enabled>true</enabled>

    </releases>

    <snapshots>

         <enabled>false</enabled>

    </snapshots>

    <layout>default</layout>

  </repository>

</repositories>

 

仓库的 id 必须是唯一的， Maven 自带的中央仓库的 id 是 central ，如果 POM 中声明的仓库 id 也是 central 会覆盖中央仓库。 releases 的 enabled 为 true ， snapshots 的 enabled 为 false ，表明该仓库只会下载 release 版本不会下载 snapshot 版本。

 

 

10.  s napshots 和 releases 中还可以包含 updatePolicy 和 checksumPolicy 两个元素 ：

updatePolicy 表示检查更新的周期，可选值为： daily （每天检查一次）， never （从不检查）， always （每次构建都检查）， interval:X （每隔 X 分钟检查一次）。默认值为 daily 。

checksumPolicy 是用来表明校验失败时如何处理，可选值为 warn ， fail ， ignore 。默认值为 warn 。

 

11.   有些远程仓库需要认证，但认证信息不宜放在 POM 中，因为 POM 一般会被提交到代码仓库中，不安全。认证信息会被配置在 settings.xml 中：

 

<servers>

  <server>

    <id>jobs</id>

    <username>usrname</username>

    <password>passw0rd</password>

  </server>

</servers> 

 

id 要和仓库的 id 保持一致。

 

12.  可 以在 POM 中配置构件想要部署到的远程仓库的信息：

 

<distributionManagement>

  <repository>

    <id>proj-release</id>

    <name>Project Release Repository</name>

    <url>http://192.168.1.100/content/repositories/proj-releases</url>

  </repository>

  <snapshortRepository>

     <id>proj-snapshot</id>

    <name>Project Snapshot Repository</name>

    <url>http://192.168.1.100/content/repositories/proj-snapshots</url>

  </snapshotRepository>

</distributionManagement> 

 

repository 中配置的是项目稳定版本（ release 版本）发布的仓库地址， snapshotRepository 中配置的是项目非稳定版本（ snapshot 版本）发布的仓库地址。认证信息同样在 settings.xml 中的 servers 元素中配置。

 

13.   Mvn clean deploy 就会将项目构建输出的构件部署到对应的远程仓库中。

 

14.   当 POM 中的项目版本定义为快照版本时，如 2.1-SNAPSHOT ， Maven 在发布项目时会将 SNAPSHOT 替换成当前时间戳。如 2.1-20111203-174413-12 表示 2011 年 12 月 3 日 17 点 44 分 13 秒的第 12 次快照。而当 POM 中声明的依赖为 SNAPSHOT 版本时， Maven 会在远程仓库中寻找最新的快照。

 

15.   快照版本只应该在组织内部的项目或模块间依赖使用，而不应该依赖于组织外部的快照版本。因为快照版本是不稳定的，今天构建成功很可能明天就构建失败。

 

16.   依赖解析机制：

    1) 依赖为 system 时，直接从本地文件系统解析。

    2)在 本地仓库寻找构件，如果发现相应构件，则解析成功。

    3)在 本地仓库找不到构件时，到所有配置的远程仓库寻找构件。

 

17.   如果依赖的版本是 RELEASE （最新 release 版本）或者 LATEST （最新版本）。（这两者 Maven3 已经不支持，只有当不指定版本号时， Maven3 默认为最新 release 版本）则基于更新策略读取所有远程仓库的 groupId/artifactId/maven-metadata.xml 中的元数据和与本地仓库中的元数据合并后，计算出真实的版本号再解析。 Metadata 信息如下：

 

<?xml version=”1.0” encoding=”UTF-8”?>

<metadata>

  <groupId>org.sonatype.nexus</groupId>

  <artifactId>nexus</artifact>

  <versioning>

    <latest>1.4.2-SNAPSHOT</latest>

    <release>1.4.0</release>

    <versions>

      <version>1.3.5</version>

      <version>1.3.6</version>

       <version>1.4.0-SNAPSHOT</version>

      …

    </versions>

    <lastUpdated>20111203180918</lastUpdated>

  </versioning>

</metadata> 

 

18.   如果依赖的版本是 SNAPSHOT ，则基于更新策略读取所有远程仓库的 groupId/artifactId/version/maven-metadata.xml 中的元数据和与本地仓库中的元数据合并后，计算出最新的快照版本的值，再进行解析。 Metadata 信息如下：

 

<?xml version=”1.0” encoding=”UTF-8”?>

<metadata>

  <groupId>org.sonatype.nexus</groupId>

  <artifactId>nexus</artifactId>

  <version>1.4.2-SNAPSHOT</version>

  <versioning>

    <snapshot>

      <timestamp>20111203.181523</timestamp>

       <buildNumber>12</buildNumber>

    </snapshot>

    …

    <lastUpdated>20111203181620</lastUpdated>

  </versioning>

</metadata>  

 

19.   远程仓库的更新策略由远程仓库配置中（ <repositories> 元素） <releases> 和 <snapshots> 中配置的 <updatePolicy> 决定，用户也可以在命令行加入参数 -U 来强制更新， Maven 就会忽略 updatePolicy 。

 

20.   如果最后解析得到的构件版本是时间戳格式的快照，如 1.4.1-20091104.121450-121 ，则复制其时间戳格式的文件至非时间戳格式，如 SNAPSHOT ，并使用该非时间戳格式的构件。何解？为什么？

 

21.   如果所有可以从仓库 A 上获得的构件都可以从仓库 B 上获得，我们称仓库 B 为仓库 A 的镜像。可以修改 settings.xml 来配置远程仓库的镜像：

 

<mirrors>

  <mirror>

    <id>maven.net.cn</id>

    <name>one of the central mirrors in China</name>

    <url>http://maven.net.cn/content/groups/public/</url>

    <mirrorOf>central</mirrorOf>

  </mirror>

  …

</mirrors>  

mirrorOf 可以取以下几种特殊值：

   * ，所有远程仓库（通常私服为所有远程仓库的镜像）

   external:* ，所有非本机上的远程仓库（使用 localhost 或 file:// 的除外）

   repo1,repo2 ，多个仓库用逗号分隔

   *, !repo1 ，所有远程仓库 repo1 除外。

 

22. 仓库搜索服务

名字	网址	特殊功能	基本功能
Sonatype Nexus	http://repository.sonatype.org/	基于checksum 搜索	关键字搜索、类名搜索、坐标搜索 生成XML 依赖声明
Jarvana	http://www.jarvana.com/jarvana/	浏览构件内部的内容 便捷的Java 文档浏览
MVNbrowser	http://www.mvnbrowser.com/	显示某个构件依赖于哪些构件以及被哪些构件引用
MVNrepository	http://mvnrepository.com/	显示某个构件各版本间的大小变化，构件之间的依赖关系

评论

1 楼 huiyibuzai 2012-07-01  

如果最后解析得到的构件版本是时间戳格式的快照，如 1.4.1-20091104.121450-121 ，则复制其时间戳格式的文件至非时间戳格式，如 SNAPSHOT ，并使用该非时间戳格式的构件。何解？为什么？

我理解的是这样的：
首先，我们的A项目版本为： 1.4.1-SNAPSHOT
通过我们的命令mvn -clean deploy部署到远程仓库后存放的版本为：1.4.1-20091104.121450-121
然后其他人在B项目中通过pom配置依赖A项目的构建版本：1.4.1-SNAPSHOT
这时需要去远程仓库拿该构建的最新快照版本（为1.4.1-20091104.121450-121），但因为我们项目中需要的版本号为：1.4.1-SNAPSHOT，所以最终使用的是该非时间戳格式的构件。这样可以保证我们使用的快照版本是远程仓库上最新的版本号