Maven的仓库

落日映苍穹つ 2021-09-20 04:08 386阅读 0赞

[2019独角兽企业重金招聘Python工程师标准>>> ][2019_Python_] ![hot3.png][]

## 仓库的概念 ##

个人理解的：简单来说就是很多构建的集合，N多的构建按照maven坐标的方式存放在这个大集合里，根据maven的坐标很容易就能够获取改构件，这个大集合就是仓库。

## 仓库的布局 ##

如上所述，每个构件都有唯一的坐标，那么根据坐标可以确定每个构件的存储路径。路径与坐标的对应方式：groupid/artifactid/version/artifactid-version-classifier.packaging

## 仓库的分类 ##

maven仓库的分类看下图:

![113015_dzyP_2464465.png][]

本地仓库：从远程仓库下载下来的构件都是存放在本地仓库的，我们在构建项目的时候都是依赖本地仓库构建的。

<settings>
        <localRepository>D:/maven/repository</localRepository>
    <settings>

在配置文件里是可以配置本地仓库的路径的。

mvn clean install  可以将构件安装到本地仓库，供本地的其他组件调用

远程仓库：

1、中央仓库：中央仓库包含了世界上绝大多数流行的开源java构件，是maven默认的远程仓库，maven自带了中央仓库的配置，中央仓库是由Sonatype出资维护的。

2、私服：私服是其他组织机构在局部范围内自己架设的maven仓库服务，它能够代理中央仓库和其他远程库，避免了组织内多个客户端频繁的去连远程库，并且可以将组织内部的构件部署在私服上供组织内部的其他构件使用。私服的优点：a、节省自己的外网带宽；b、加速maven构建；c、部署第三方构件；d、提高稳定，增强控制；e、降低中央仓库的负荷。

3、其他公共库：如java.net 和jboss maven库

## 远程仓库的配置 ##

仓库的配置可以在项目pom里配置，也可以在settings文件里配置：

<repositories>
                    <repository>
                        <snapshots>
                            <enabled>false</enabled>
                        </snapshots>
                        <id>central</id>
                        <name>repo</name>
                        <url>http://maven:8081/artifactory/repo</url>
                    </repository>
                    <repository>
                        <snapshots>
    						<updatePolicy>always</updatePolicy>
    				    </snapshots>
                        <id>snapshots</id>
                        <name>repo</name>
                        <url>http://maven:8081/artifactory/repo</url>
                    </repository>
                </repositories>

id:该仓库的唯一标识,不能重复

name:仓库的名字

url:仓库地址

snapshots / releases:

enable:   true or false 表示开启关闭对远程仓库的 快照和发布版本的下载支持

updatePolicy:  更新策略，daliy——一天一次，never——从不检查，always——每次构建都检查，interval:X——每隔X分钟检查一次。

checksumPolicy: 检查检验和文件的策略，ignore：检验和验证失败，忽略；fail: 校验和验证失败，让构建失败；warn: 校验和验证失败，让maven提示，输出警告信息。

**远程仓库的验证**：

有些远程仓库可能需要验证才能访问，所以我们需要配置maven的验证，验证的配置一般都是在settings.xml文件中进行配置（比较安全）：

<servers>
            <server>
                <id>release</id>
                <username>admin</username>
                <password>admin123</password>
            </server>
            <server>
                <id>snapshot</id>
                <username>admin</username>
                <password>admin123</password>
            </server>
        </servers>

servers 下可以配置多个 server ,每个server代表一个仓库：

id:对应与repository 的Id，必须要完全一致

username: 验证用的用户名

password: 验证用的密码

**部署到远程仓库**

<distributionManagement>
        <repository>
          <id>ext-release-local</id>
          <name>ext-release-local</name>
          <url>http://maven/artifactory/ext-release-local/</url>
        </repository>
        <snapshotRepository>
              <id>ext-snapshot-local</id>
              <name>ext-snapshot-local</name>
              <url>http://maven/artifactory/ext-snapshot-local/</url>
         </snapshotRepository>
      </distributionManagement>

**repository:**

**                **发布版本构件仓库

**snapshotRepository:**

**               ** 快照版本仓库构建

配置好之后如需要部署构件到仓库，执行：mvn clean deploy

## 快照的版本 ##

快照只应该在组织内部项目或则依赖间使用；快照使用的场景：A项目依赖B项目，B项目也在开发中，没有正式发布，那么A可以依赖B的快照版本（SNAPSHOT）。在发布快照版本的时候，maven会自动为构建打上时间戳和构建次数（如：2.1.0-20171220.142820-12）,当其他项目依赖该模块构建的的时候maven会自动找到snapshot的最新版本。但是需要注意的是，maven的更新策略，默认是一天一次，如果需要强制更新可以 加上参数 -U ,如：mvn clean install -U ;或则更改仓库的更新策略。

## 依赖解析的机制 ##

maven依赖解析的步骤如下：

1、当依赖范围是system的时候，直接从配置的路径加载依赖

2、根据配置的maven坐标，在本地仓库加载

3、若在本地仓库没有找到相关构建，并且构件的版本是显式配置的，则去配置的远程仓库遍历寻找，找到就解析成功

4、如果依赖的版本是 RELEASE 或者 LASTER，则基于更新策略去检查maven仓库的元数据：groupid/artifactid/maven-metadata.xml，然后和本地仓库对应的元数据进行合并，得到RELEASE或则LASTER的真实，按照2）,3)去检索依赖。

5、如果依赖的版本是SNAPSHOT，则基于更新策略去检查maven仓库的元数据，groupid/artifactid/version/maven-metadata.xml，然后和本地仓库对应的元数据进行合并，得到快照的最新版，然后从本地或则远程仓库检索。如果检索到的是带时间戳格式的快照，那么将时间戳格式的快照复制为非时间戳格式，并使用该非时间戳格式的构件。

## 仓库的镜像 ##

能够替代原仓库，提供跟原仓库相同服务的仓库我们该仓库是原仓库的镜像。

<mirrors>
    		 <mirror>
                <id>nexus</id>
                <mirrorOf>*</mirrorOf>
                <name>Human Readable Name for this Mirror.</name>
                <url>http://127.0.0.1:8081/nexus/content/groups/public</url>
            </mirror>
    		
            <mirror>
                <id>bsfit</id>
                <name>bangsun Central</name>
                <url>http://127.0.0.1:8081/nexus/content/groups/public</url>
                <mirrorOf>central</mirrorOf>
            </mirror>
    
            <mirror>
                <id>bsfit-snapshots</id>
                <mirrorOf>snapshots</mirrorOf>
                <name>bangsun snapshots</name>
                <url>http://127.0.0.1:8081/nexus/content/groups/public</url>
            </mirror>
    
        </mirrors>

mirros下可以包含多个mirror;

id、name、url，与普通仓库的配置是一样的，要是需要验证，也是可以配置基于id的验证。

mirrorOf: 这个表示被镜像的仓库id,

mirrorOf 常见的配置方法如下：

<mirrorOf>\*</mirrorOf> : 所有仓库镜像，一般建议放在最后

<mirrorOf>repo1,repo2</mirrorOf> ： repo1,reop2的镜像

<mirrorOf>external:\*</mirrorOf> ： 匹配所有不在本机上的远程仓库

<mirrorOf>\*,!repo1</mirrorOf> ： 匹配所有远程仓库除了repo1

多个mirrors,会根据申明的顺序来挨个匹配；同一个mirrorof内部，逗号分割后挨个匹配

转载于:https://my.oschina.net/u/2464465/blog/1592670

[2019_Python_]: https://my.oschina.net/u/2663968/blog/3061697
[hot3.png]: /images/20210726/d60d038747ed40fc8d10a4f36f31ffb3.png
[113015_dzyP_2464465.png]: https://static.oschina.net/uploads/space/2017/1220/113015_dzyP_2464465.png