Maven——仓库_maven仓库

仓库的布局方式  groupId/artifactId/version/artifactId-version.package

Maven仓库

本地仓库   在第一条mvn命令后自动创建

<localRepository>D:\Program Files\apache-maven-3.2.2-repository</localRepository>  在用户或全局配置文件中配置

中央存库

<repositories>

           <repository>

                     <id>central</id>

                     <name>Central Repository</name>         

                     <url>http://repo.maven.apache.org/maven2</url>         

                     <layout>default</layout>         

                     <snapshots>

                         <enabled>true</enabled>

                         <updatePolicy>always</updatePolicy>

                         <checksumPolicy>ignore</checksumPolicy>

                     </snapshots> 

            </repository> 

    </repositories>

snapshots中的enabled 为false 代表关闭快照版本的下载支持

updatePolicy用来配置Maven从远程仓库检查更新的频率，默认值是daily，表示Maven每天检查一次。其他可用的值包括：never——从不检测更新；always——每次构建都检查更新；interval:X——每隔X分钟检查一次更新（X为任意整数）

checksumPolicy用来配置Maven检查验证和文件的策略。当构建被部署到Maven仓库中时，会同时部署对应的检验和文件。在下载构建的时候，Maven会验证校验和文件，如果校验和验证失败，怎么办？当checksumPolicy的值为默认的warn时，Maven会在执行构建时输出警告信息，其他可用值包括：fail——Maven遇到校验和错误就让构造失败；ignore——使Maven完全忽略校验和错误。

私服

远程仓库认证

    有时候登录一个远程仓库需要用户名和密码进行身份验证，所以，需要远程仓库认证。配置认证信息和配置仓库信息不同，仓库信息可以直接配置POM文件中，但是认证信息必须配置在settings.xml文件中，目的就是安全性。当然，我们可以把仓库信息配置在settings.xml 中，这样的缺点就是好动态控制仓库，但是一般情况下不会改变仓库，我们本地私服一般都是唯一的。

<server>

<id>deploymentRepo_releases</id>

<username>repouser</username>

<password>repopwd</password>

</server>

值得注意的是，ID代表的是某个repository元素配置的ID。

远程仓库部署

<distributionManagement>

<repository>

<id>deploymentRepo_releases</id>

<name>Nexus Release Repository</name>

<url>http://localhost:8081/nexus/content/repositories/releases/</url>

</repository>

<snapshotRepository>

<id>deploymentRepo_snapshots</id>

<name>Nexus Snapshot Repository</name>

<url>http://localhost:8081/nexus/content/repositories/snapshots/</url>

</snapshotRepository>

</distributionManagement>

我们开发的版本可以通过 mvn deploy 把项目部署到对应的私服上去对于为什么要把发行版本和快照版本分开主要还是为了方便后期项目维护和当时的协同开发。比如发行版本肯定是稳定版，但是他的功能可能没有那么多，对于一些要求稳定的客户就可以给他发行版本；可是对于快照版本来说，是一个正在开发的版本，这个版本可能随时都会被另外一个项目依赖，如果他需要我的功能我就会进行代码提交，也就是部署到私服上去，然而，这个时候Maven就会把我的快照版本做一个时间戳添加在快照版本之后，别人依赖的快照版本也会自动更新为最新的快照版本，这些都是Maven帮我们完成，我们只要项目提交就好。

镜像

    如果仓库X可以提供仓库Y存储的所有内容，那么就可以认为X是Y的一个镜像，某些情况下使用镜像可以提高项目构建效率。

    settings.xml 中配置镜像

<mirrors>

<mirror>

<id>mirrorId</id>

<mirrorOf>repositoryId</mirrorOf>

<name>Human Readable Name for this Mirror.</name>

<url>http://my.repository.com/repo/path</url>

</mirror>

</mirrors>

镜像的意思是，当你访问mirrorOf的仓库时，就会转到对应的镜像url中请求对应的资源。一般镜像都是和私服结合使用。由于私服可以代理任何外部的公共仓库（包括中央仓库），因此，对于组织内部的Maven用户来说，使用一个私服地址就等于使用了所有需要的外部仓库，这个可以将配置集中到私服，从而简化Maven本身的配置。在这种情况下，任何需要的构件都可以从私服中获得，私服就是所有仓库的镜像。这猴子那个镜像如下配置：

<mirrors>

<mirror>

<id>mirrorId</id>

<mirrorOf>*</mirrorOf>

<name>Human Readable Name for this Mirror.</name>

<url>http://my.repository.com/repo/path</url>

</mirror>

</mirrors>

从仓库解析依赖的机制  看Maven实战那本书的第6章

当本地仓库没有依赖构建的时候，Maven会自动从远程仓库下载；当依赖版本为快照版本的时候，Maven会自动找到最新的快照。这背后的依赖机制可以概括如下：

1.当依赖的范围是system的时候，Maven直接从本地文件系统解析构件。

2.根据依赖坐标计算仓库路径后，尝试直接从本地仓库寻找构件，如果发现相应构件，则解析成功。

3.在本地仓库不存在相应构件的情况下，如果依赖的版本是显示的发布版本构件，如1.2、2.1-beta-1等，则遍历所有的远程仓库，发现后，下载解析使用。

4.如果依赖的版本是RELEASE或者LATEST，则基于更新策略读取所有远程仓库的元数据groupId/artifactId/maven-metadata.xml,将其与本地仓库的对应元数据合并后，计算出RELEASE或者LATEST真实的值，然后基于这个真是的值检验本地仓库和远程仓库，如步骤2，步骤3.

5.如果依赖的版本是SNAPSHOT,则基于更新更新策略读取所有远程仓库的元数据/groupId/artifactId/maven-metadata.xml，将其与本地仓库的对应元数据合并后，得到最新的快照版本的值，然后基于该值检查本地仓库，或者从远程仓库下载。

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

当依赖的版本不明确的时候，如RELEASE、LATEST和SNAPSHOT，Maven就需要基于更新远程仓库的更新策略来检查更新。首先是<releases> <enabled> 和 <snapshots> <enabled>,只有谷仓开启了对发布版本的支持时，才能访问该仓库的发布版本构件信息，对于快照版本也是同理；其次要注意的是检查更新、永久检查更新、从不检查更新、自定义时间间隔检查更新等。最后，用户还可以从命令行加入参数-U，强制检查更新，使用参数后，Maven就会忽略<updatePolicy>的配置。

在依赖声明中使用RELEAS和LATEST是不推荐的做法。

RELEAS是最新的发布版构件，LATEST是最新的发布版或快照版构件。

仓库搜索服务：Sonatype Nexus、Jarvana、MVNbrowser、MVNrepository