仓库分类
对于Mavne来说，仓库只分为两类：本地仓库和远程仓库。当Maven根据坐标查询寻找构件的时候，它首先会查看本地仓库，如果本地仓库存在此构件，则直接使用；如果本地仓库不存在此构件，或者需要查看是否有更新的构件版本，Maven就会去远程仓库查找，发现需要的构件之后，下载到本地仓库在使用。如果本地仓库和远程仓库都没有需要的构件，Maven就会报错。
本地仓库
安装好maven后，如果不执行任何maven命令，本地仓库目录是不存在的，当用户输入第一条命令时，maven才会创建本地仓库，Linux或者Windows系统默认的本地仓库目录为用户目录下 .m2/repository/，然后根据配置和需要，从远程仓库下载构件至本地仓库。
通过修改Maven安装目录/conf/settings.xml文件或者.m2/settings.xml文件，设置localRepository属性指定本地仓库的目录地址
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
<!-- localRepository
| The path to the local repository maven will use to store artifacts.
| Default: ${user.home}/.m2/repository
-->
<localRepository>/path/to/local/repo</localRepository>
</settings>通过本地项目中执行 mvn clean install命令可以将本地项目安装到本地库中。
远程仓库
中央仓库是默认的远程仓库，Maven的安装文件自带了中央仓库的配置。安装目录lib子目录下maven-model-builder-xxx.jar包中
org\apache\maven\model\pom-xxx.xml文件中可以看到
<repositories>
<repository>
<id>central</id>
<name>Central Repository</name>
<url>https://repo.maven.apache.org/maven2</url>
<layout>default</layout>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>中央仓库包含了世界上绝大多数流行的开源Java构件，以及源码、作者信息、SCM信息、许可证信息等。
私服是一种特殊的远程仓库，它是假设在局域网内的仓库服务，私服代理广域网上远程仓库，供局域网内的Maven用户使用。当Maven需要下载构件的时候从私服请求，如果私服不存在则从外部的远程仓库下载缓存到私服上之后，再为Maven的下载请求提供服务。一些无法从外部仓库下载到的构件以及组织内部生成的构件也能从本地上传到私服上供开发者使用。
配置远程仓库
<repositories>
<repository>
<id>jboss</id>
<name>Jboss Repository</name>
<url>http://repository.jboss.com/maven2</url>
<layout>default</layout>
<releases>
<enabled>true</enabled>
<updatePolicy>daily</updatePolicy>
<checksumPolicy>ignore</checksumPolicy>
</releases>
<snapshots>
<enabled>false</enabled>
<updatePolicy>daily</updatePolicy>
<checksumPolicy>ignore</checksumPolicy>
</snapshots>
<layout>default</layout> <!-- default 表示仓库的布局是Maven2及Maven3的默认布局，而不是Maven1的布局-->
</repository>
</repositories>仓库id必须是唯一的，Maven中央仓库的id为central,如果其他仓库也使用该id，就会覆盖中央仓库的配置。
updatePolicy：用来配置Maven从远程仓库检查更新的频率，默认值是daily,表示每天更新一次；never表示从不检查更新；always表示每次构件都检查更新；interval:X 表示每隔X分钟检查一次更新。命令行加人参数-U，强制检查更新，使用参数后，Maven 就会忽路＜updatoPolioy＞的配置
checksumPolicy：用来配置Maven检查检验和文件的策略。仓库部署到仓库中时会同时部署对应的校验和文件。再下载构件的时候Maven会验证校验和文件，如果校验失败时，根据checksumPolicy的属性值做出不同的反应
warn：输出警告信息，为默认值
fail：让构建失败
ignore：完全忽略校验和错误
还可以在settings.xml文件中配置镜像来访问远程仓库。
远程仓库认证
如果远程仓库需要账号密码认证的话，仓库信息可以直接配置在POM文件中，需要在setting.xml文件中配置认证信息。例如
<servers>
<!-- server
| Specifies the authentication information to use when connecting to a particular server, identified by
| a unique name within the system (referred to by the 'id' attribute below).
|
| NOTE: You should either specify username/password OR privateKey/passphrase, since these pairings are
| used together.
|
<server>
<id>deploymentRepo</id>
<username>repouser</username>
<password>repopwd</password>
</server>
-->
<!-- Another sample, using keys to authenticate.
<server>
<id>siteServer</id>
<privateKey>/path/to/private/key</privateKey>
<passphrase>optional; leave empty if not used.</passphrase>
</server>
-->
</servers>server元素的id必须与POM中需要认证的repository元素的id一致。正是这个id将认证信息与仓库配置联系在了一起。
部署构件到远程仓库
开发时将本地编译好的项目部署到仓库中，供其他团队成员使用，需要配置项目的pom.xml文件。例如
<distributionManagement>
<repository>
<id/>nexus-releases</id>
<name>Nexus Releases Repository</name>
<url/>http://localhost:8081/nexus/content/repositories/releases/</url>
</repository>
<snapshotRepository>
<id>nexus-snapshots</id>
<name>Nexus Snapshots Repository</name>
<url/>http://localhost:8081/nexus/content/repositories/snapshots/
</snapshotRepository>
</distributionManagement>部署构件与下载构件相同，当需要认证的时候配置的方式是一样的。
本地项目执行命令mvn clean deploy可以将项目部署到远程仓库中。
从仓库解析依赖的机制
当本地仓库没有依赖构件的时候，Maven 会自动从远程仓库下载；当依赖版本为快照
版本的时候，Maven 会自动找到最新的快照。这背后的依赖解析机制可以概括如下：
1）当依赖的范围是 syslem 的时候，Maven 直接从本地文件系统解析构件。
2）根据依赖坐标计算仓库路径后，尝试直接从本地仓库导找构件，如果发现相应构件，则解析成功。
3）在本地仓库不存在相应构件的情况下，如果依赖的版本是显式的发布版本构件，如1.2、2.1-beta-1 等，则遍历所有的远程仓库，发现后，下载并解析使用。
4）如果依赖的版本是 RELEASE 或者 LATEST,则基于更新策略读取所有远程仓库的元数据 groupld/artifactld/ maven-metadala.xml，将其与本地仓库的对应元数据合并后，计算出 RELEASE或者LATEST 真实的值，然后基于这个真实的值检查本地和远程仓库，如步骤2） 和3）。
5） 如果依赖的版本是 SNAPSHOT，则基于更新策略读取所有远程仓库的元数据 groupld/ artifactld/ version/ maven-meladata xml，将其与本地仓库的对应元数据合井后，得到最新快照版本的值，然后基于该值检查本地仓库，或者从远程仓库下载。
6）如果最后解析得到的构件版本是时间戳格式的快照，如 1.4.1-20091104.121450-121,则复制其时间戳格式的文件至非时间戳格式，如 SNAPSHOT，并使用该非时间戳格式的构件。
当依赖的版本不明哳的时候，如 RELEASE、LATEST 和 SNAPSHOT， Maven 就需要基于更新远程仓库的更新策略来检查更新。
用户还可以从命令行加人参数-U，强制检查更新，使用参数后，Maven 就会忽路＜updatoPolioy＞的配置。
当Maven 检查完更新策略，并决定检检查依赖更新的时候，就看要检查仓库元数据 maven-metadata. xml。
Maven通过合并多个远程仓库及本地仓库的元数据计算出基于所有仓库的latest和release分别是什么，然后再解析具体的构件。
快照版本的解析过程和release和latest版本类似，1.4.2-20091214.221414-13 版本号-时间戳-构建号。
Maven3不再支持在插件配置中使用LATEST和RELEASE，如果不设置插件版本，其效果就和RELEASE一样，Maven只会解析最新的发布版本构件
镜像-仓库的备份
仓库X可以提供仓库Y存储的所有内容，那么就可以认为X是Y的一个镜像。任何一个可以从仓库Y获得的构件都能够从它的镜像中获取。
配置Maven使用该镜像来替代中央仓库。编辑settiings.xml文件
<settiings>
...
<mirrors>
<mirror>
<id > maven. net. cn </id>
<name > one of the central mirrors in China < /name >
<ur1>http://maven.net.cn/content/groups/public/</url>
<mirrorOf > central < /mirrorOf>
</mirror>
</mirrors >
...
<settings>该例子中，
关于镜像的一个更为常见的用法是结合私服。由于私服可以代理任何外部的公共仓库(包括中央仓库)，因此，对于组织内部的 Maven 用户来说，使用一个私服地址就等于使用了所有需要的外部仓库，这可以将配置集中到私服，从而简化 Maven 本身的配置。在这种情况下，任何需要的构件都可以从私服获得，私服就是所有仓库的镜像。这时，可以配置这样的一个镜像，见代码清单。
<settiings>
...
<mirrors>
<mirror>
<id > internal-repository</id>
<name > Internal Repository Manager< /name >
<ur1>http://192.168.1.100</url>
<mirrorOf > * < /mirrorOf>
</mirror>
</mirrors >
...
<settings>该例中的值为星号，没示该配置是所有 Maven 仓库的镜像，任何对于运程仓库的请求都会被转至http://192. 16. 1.100/ maven2/。如果该镜像仓库需要认证，则配一个id为inlenal-repository 的＜server＞即可。<>
为了满足一些复杂的需求，Maven 还支持更高级的镜像配置：
* ：匹配所有远程仓库。
external: *
repol,repo2 ：匹配仓库 repol 和repo2，使用逗号分割多个远程仓库。
*,!repo1：匹配所有远程仓库，repo1除外，使用感叹号将仓库从匹配中排除。
需要注意的是，由于镜像仓库完全屏蔽了被镜像仓库，当镜像仓库不稳定或者停止服务的时候，Maven 仍将无法访问被镜像仓车，因而将无法下载构件。
仓库搜索软件
Sonatype Nexus、Jarvana、MVNbrowser、MVNrepository
扫一扫
927
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
