Maven详解之仓库------本地仓库、远程仓库
在Maven中，任何一个依赖、插件或者项目构建的输出，都可以称之为构件。
Maven在某个统一的位置存储所有项目的共享的构件，这个统一的位置，我们就称之为仓库。（仓库就是存放依赖和插件的地方）
任何的构件都有唯一的坐标，Maven根据这个坐标定义了构件在仓库中的唯一存储路径，
解读Maven在仓库中的存储路径：
1.基于groupId准备路径，将句点分隔符转成路径分隔符，就是将 "." 转换成 "/" ; example： org.testng --->org/testng
2.基于artifactId准备路径，将artifactId连接到后面：org/testng/testng
3.使用version准备路径，将version连接到后面：org/testng/testng/5.8
4.将artifactId于version以分隔符连字号连接到后面：org/testng/testng/5.8/tesng-5.8
5.判断如果构件有classifier，就要在 第4项 后增加 分隔符连字号 再加上 classifier，org/testng/testng/5.8/tesng-5.8-jdk5
6.检查构件的extension，如果extension存在，则加上句点分隔符和extension，而extension是由packing决定的，org/testng/testng/5.8/tesng-5.8-jdk5.jar
到这里我们就明白了Maven 对于构件存储的细节。
Maven 仓库的分类：
maven的仓库只有两大类：
1.本地仓库
2.远程仓库，在远程仓库中又分成了3种：
2.1 中央仓库
2.2 私服
2.3 其它公共库
1.本地仓库
顾名思义，就是Maven在本地存储构件的地方。
注：maven的本地仓库，在安装maven后并不会创建，它是在第一次执行maven命令的时候才被创建
maven本地仓库的默认位置：无论是Windows还是Linux，在用户的目录下都有一个.m2/repository/的仓库目录，这就是Maven仓库的默认位置
如何更改maven默认的本地仓库的位置：这里要引入一个新的元素：localRepository，它是存在于maven的settings.xml文件中
1.1 更改配置用户范围的本地仓库：
先在/.m2/目录下创建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>D:/myworkspace/maven_repository</localRepository> <!-- interactiveMode | This will determine whether maven prompts you when it needs input. If set to false, | maven will use a sensible default value, perhaps based on some other setting, for | the parameter in question. | | Default: true <interactiveMode>true</interactiveMode> --> ... ...
这时候，maven的本地仓库地址就变成了 D:\maven_new_repository ，注：此时配置的maven的本地仓库是属于用户范围的。
1.2 更改配置全局范围的本地仓库：
在M2_HOME/conf/settings.xml(D:\soft\maven\apache-maven-3.3.3\confsettings.xml\settings.xml)中更改配置，更改配置的方法同上
注：此时更改后，所有的用户都会受到影响，而且如果maven进行升级，那么所有的配置都会被清除，所以要提前复制和备份M2_HOME/conf/settings.xml文件
故：一般情况下不推荐配置全局的settings.xml
1.3 工程使用仓库配置的优先级顺序
这个确实是有个优先级的，应该是pom>用户级别>全局级别
例：如果pom中不配置，就取用户级别，如果用户级别也没有配置，就取全局级别
2. 远程仓库
2.1 说到远程仓库先从 最核心的中央仓库开始，中央仓库是默认的远程仓库，maven在安装的时候，自带的就是中央仓库的配置
在maven的聚合与继承中我们说过，所有的maven项目都会继承超级pom，具体的说，包含了下面配置的pom我们就称之为超级pom
<repositories> <repository> <id>central</id> <name>Central Repository</name> <url>http://repo.maven.apache.org/maven2</url> <layout>default</layout> <snapshots> <enabled>false</enabled> </snapshots> </repository> </repositories>
中央仓库包含了绝大多数流行的开源Java构件，以及源码、作者信息、SCM、信息、许可证信息等。一般来说，简单的Java项目依赖的构件都可以在这里下载得到。
2.2 私服
私服是一种特殊的远程仓库，它是架设在局域网内的仓库服务，私服代理广域网上的远程仓库，供局域网内的Maven用户使用。当Maven需要下载构件的时候，它从私服请求，如果私服上不存在该构件，则从外部的远程仓库下载，缓存在私服上之后，再为Maven的下载请求提供服务。我们还可以把一些无法从外部仓库下载到的构件上传到私服上。
Maven私服的 个特性：
1.节省自己的外网带宽：减少重复请求造成的外网带宽消耗
2.加速Maven构件：如果项目配置了很多外部远程仓库的时候，构建速度就会大大降低
3.部署第三方构件：有些构件无法从外部仓库获得的时候，我们可以把这些构件部署到内部仓库(私服)中，供内部maven项目使用
4.提高稳定性，增强控制：Internet不稳定的时候，maven构建也会变的不稳定，一些私服软件还提供了其他的功能
5.降低中央仓库的负荷：maven中央仓库被请求的数量是巨大的，配置私服也可以大大降低中央仓库的压力
当前主流的maven私服：
1.Apache的Archiva
2.JFrog的Artifactory
3.Sonatype的Nexus
三、远程仓库配置
配置远程仓库将引入新的配置元素：
在**
例子：
<repositories> <repository> <id>jboss</id> <name>JBoss Repository</name> <url>http://repository.jboss.com/maven2/</url> <releases> <updatePolicy>daily</updatePolicy><!-- never,always,interval n --> <enabled>true</enabled> <checksumPolicy>warn</checksumPolicy><!-- fail,ignore --> </releases> <snapshots> <enabled>false</enabled> </snapshots> <layout>default</layout> </repository> </repositories>
出于安全方面的考虑，有时我们要对远程仓库的访问进行认证，一般将认证信息配置在settings.xml中：
<servers> <server> <id>same with repository id in pom</id> <username>username</username> <password>pwd</password> </server> </servers>
注：这里的id必须与POM中需要认证的repository元素的Id一致。
如何将生成的项目部署到远程仓库
完成这项工作，也需要在POM中进行配置，这里有新引入了一个元素：
distributionManagement包含了2个子元素：repository和snapshotRepository, 前者表示发布版本构件的仓库，后者表示快照版本的仓库
这两个元素都需要配置 id(该远程仓库的唯一标识)，name，url(表示该仓库的地址)
向远程仓库中部署构件，需要进行认证。配置同上
配置正确后运行： mvn clean deploy
正确的看待快照
之前我们在配置pom的时候，对于快照的配置都很谨慎，或者说很少用快照的版本，原因是它还很不稳定，极容易给我们的系统带来未知的错误，让我们很难查找。其实快照版本也并不是一无是处，快照最大的用途是用在开发的过程中，尤其是有模块依赖的时候，比如说AB两个模块同时开发，A依赖于B，开发过程中AB都是持续集成的开发，不断的修改POM文件和构建工程，这时候版本同步就成了一个很大的问题。使用快照就可以达到这一目的。
其实在快照版本在发布的过程中，Maven会自动为构件以当前时间戳做标记，有了这个时间戳，我们就可以随时找到最新的快照版本，这样也就解决刚才说的 协作开发的问题。
至于A如何检查B的更新，刚刚在讲配置的时候说过，快照配置中有一个元素可以控制检查更新的频率------updatePolicy
我们也可以使用命令行加参数的形式强制执行让maven检查更新：
mvn clean install-U
maven到底是如何从仓库中解析构件的呢？----maven从仓库解析依赖的机制
1. 当依赖的范围是system的时候，Maven直接从本地文件系统解析构件
2. 根据依赖坐标计算仓库路径后，尝试直接从本地仓库寻找构件，如果发现相应构件，则解析成功
3. 在本地仓库不存在相应的构件情况下，如果依赖的版本是显示的发布版本构件，则遍历所有的远程仓库，发现后下载使用
4. 如果依赖的版本是RELEASE或LATEST, 则基于更新策略读取所有远程仓库的元数据，将其于本地仓库的对应元数据合并后，计算出RELEASE或者LATEST的真实值，然后基于这个真实值检查本地仓库
5. 如果依赖的版本是SNAPSHOT， 则基于更新策略读取所有远程仓库的元数据， 将其与本地仓库的对应元数据合并后，得到最新快照版本的值，然后基于该值检查本地仓库或从远程仓库下载
6. 如果最后解析到的构件版本是时间戳格式的快照，则复制其时间戳格式的文件 至 非时间戳格式，并使用该非时间戳格式的构件
注：一定要记得
在POM的依赖声明的时候不推荐使用LATEST & RELEASE, 在Maven3中也不再支持在插件配置中使用LATEST & RELEASE， 如果不设置插件版本，那么最终版本和release一样，
maven只会解析最新的发布版本构建。
1.远程仓库的配置
在平时的开发中，我们往往不会使用默认的中央仓库，默认的中央仓库访问的速度比较慢，访问的人或许很多，有时候也无法满足我们项目的需求，可能项目需要的某些构件中央仓库中是没有的，而在其他远程仓库中有，如JBoss Maven仓库。这时，可以在pom.xml中配置该仓库，代码如下：
1 <!-- 配置远程仓库 --> 2 <repositories> 3 <repository> 4 <id>jboss</id> 5 <name>JBoss Repository</name> 6 <url>http://repository.jboss.com/maven2/</url> 7 <releases> 8 <enabled>true</enabled> 9 <updatePolicy>daily</updatePolicy> 10 </releases> 11 <snapshots> 12 <enabled>false</enabled> 13 <checksumPolicy>warn</checksumPolicy> 14 </snapshots> 15 <layout>default</layout> 16 </repository> 17 </repositories>
repository：在repositories元素下，可以使用repository子元素声明一个或者多个远程仓库。
id：仓库声明的唯一id，尤其需要注意的是，Maven自带的中央仓库使用的id为central，如果其他仓库声明也使用该id，就会覆盖中央仓库的配置。
name：仓库的名称，让我们直观方便的知道仓库是哪个，暂时没发现其他太大的含义。
url：指向了仓库的地址，一般来说，该地址都基于http协议，Maven用户都可以在浏览器中打开仓库地址浏览构件。
releases和snapshots：用来控制Maven对于发布版构件和快照版构件的下载权限。需要注意的是enabled子元素，该例中releases的enabled值为true，表示开启JBoss仓库的发布版本下载支持，而snapshots的enabled值为false，表示关闭JBoss仓库的快照版本的下载支持。根据该配置，Maven只会从JBoss仓库下载发布版的构件，而不会下载快照版的构件。
layout：元素值default表示仓库的布局是Maven2及Maven3的默认布局，而不是Maven1的布局。基本不会用到Maven1的布局。
其他：对于releases和snapshots来说，除了enabled，它们还包含另外两个子元素updatePolicy和checksumPolicy。
元素updatePolicy用来配置Maven从远处仓库检查更新的频率，默认值是daily，表示Maven每天检查一次。其他可用的值包括：never-从不检查更新；always-每次构建都检查更新；interval：X-每隔X分钟检查一次更新（X为任意整数）。
元素checksumPolicy用来配置Maven检查校验和文件的策略。当构建被部署到Maven仓库中时，会同时部署对应的检验和文件。在下载构件的时候，Maven会验证校验和文件，如果校验和验证失败，当checksumPolicy的值为默认的warn时，Maven会在执行构建时输出警告信息，其他可用的值包括：fail-Maven遇到校验和错误就让构建失败；ignore-使Maven完全忽略校验和错误。
2.远程仓库的认证
大部分公共的远程仓库无须认证就可以直接访问，但我们在平时的开发中往往会架设自己的Maven远程仓库，出于安全方面的考虑，我们需要提供认证信息才能访问这样的远程仓库。配置认证信息和配置远程仓库不同，远程仓库可以直接在pom.xml中配置，但是认证信息必须配置在settings.xml文件中。这是因为pom往往是被提交到代码仓库中供所有成员访问的，而settings.xml一般只存在于本机。因此，在settings.xml中配置认证信息更为安全。
1 <settings> 2 2 ... 3 3 <!--配置远程仓库认证信息--> 4 4 <servers> 5 5 <server> 6 6 <id>releases</id> 7 7 <username>admin</username> 8 8 <password>admin123</password> 9 9 </server> 10 10 </servers> 11 11 ... 12 12 </settings>
上面代码我们配置了一个id为releases的远程仓库认证信息。Maven使用settings.xml文件中的servers元素及其子元素server配置仓库认证信息。认证用户名为admin，认证密码为admin123。这里的关键是id元素，settings.xml中server元素的id必须与pom.xml中需要认证的repository元素的id完全一致。正是这个id将认证信息与仓库配置联系在了一起。
3.部署构件至远程仓库
我们使用自己的远程仓库的目的就是在远程仓库中部署我们自己项目的构件以及一些无法从外部仓库直接获取的构件。这样才能在开发时，供其他对团队成员使用。
Maven除了能对项目进行编译、测试、打包之外，还能将项目生成的构件部署到远程仓库中。首先，需要编辑项目的pom.xml文件。配置distributionManagement元素，代码如下：
1 <distributionManagement> 2 <repository> 3 <id>releases</id> 4 <name>public</name> 5 <url>http://59.50.95.66:8081/nexus/content/repositories/releases</url> 6 </repository> 7 <snapshotRepository> 8 <id>snapshots</id> 9 <name>Snapshots</name> 10 <url>http://59.50.95.66:8081/nexus/content/repositories/snapshots</url> 11 </snapshotRepository> 12 </distributionManagement>
distributionManagement包含repository和snapshotRepository子元素，前者表示发布版本（稳定版本）构件的仓库，后者表示快照版本（开发测试版本）的仓库。这两个元素都需要配置id、name和url，id为远程仓库的唯一标识，name是为了方便人阅读，关键的url表示该仓库的地址。
往远程仓库部署构件的时候，往往需要认证，配置认证的方式同上。
配置正确后，运行命令mvn clean deploy，Maven就会将项目构建输出的构件部署到配置对应的远程仓库，如果项目当前的版本是快照版本，则部署到快照版本的仓库地址，否则就部署到发布版本的仓库地址。
快照版本和发布版本的区别请自行上百度查阅资料。
4.配置远程仓库的镜像
如果仓库X可以提供仓库Y存储的所有内容，那么就可以认为X是Y的一个镜像。换句话说，任何一个可以从仓库Y获得的构件，都能够从它的镜像中获取。举个例子，http://maven.oschina.net/content/groups/public/ 是中央仓库http://repo1.maven.org/maven2/ 在中国的镜像，由于地理位置的因素，该镜像往往能够提供比中央仓库更快的服务。因此，可以配置Maven使用该镜像来替代中央仓库。编辑settings.xml，代码如下：
1 <mirrors> 2 <mirror> 3 <id>maven.oschina.net</id> 4 <name>maven mirror in China</name> 5 <url>http://maven.oschina.net/content/groups/public/</url> 6 <mirrorOf>central</mirrorOf> 7 </mirror> 8 </mirrors>
该例中，mirrorOf的值为central，表示该配置为中央仓库的镜像，任何对于中央仓库的请求都会转至该镜像，用户也可以使用同样的方法配置其他仓库的镜像。id表示镜像的唯一标识符，name表示镜像的名称，url表示镜像的地址。
关于镜像的一个更为常见的用法是结合私服。由于私服可以代理任何外部的公共仓库(包括中央仓库)，因此，对于组织内部的Maven用户来说，使用一个私服地址就等于使用了所有需要的外部仓库，这可以将配置集中到私服，从而简化Maven本身的配置。在这种情况下，任何需要的构件都可以从私服获得，私服就是所有仓库的镜像。这时，可以配置这样的一个镜像：
1 <!--配置私服镜像--> 2 <mirrors> 3 <mirror> 4 <id>nexus</id> 5 <name>internal nexus repository</name> 6 <url>http://183.238.2.182:8081/nexus/content/groups/public/</url> 7 <mirrorOf>*</mirrorOf> 8 </mirror> 9 </mirrors>
该例中
需要注意的是，由于镜像仓库完全屏蔽了被镜像仓库，当镜像仓库不稳定或者停止服务的时候，Maven仍将无法访问被镜像仓库，因而将无法下载构件。
5.可用的Maven镜像仓库
1 <mirror> 2 <id>repo2</id> 3 <mirrorOf>central</mirrorOf> 4 <name>Human Readable Name for this Mirror.</name> 5 <url>http://repo2.maven.org/maven2/</url> 6 </mirror> 7 8 <mirror> 9 <id>ui</id> 10 <mirrorOf>central</mirrorOf> 11 <name>Human Readable Name for this Mirror.</name> 12 <url>http://uk.maven.org/maven2/</url> 13 </mirror> 14 15 16 <mirror> 17 <id>ibiblio</id> 18 <mirrorOf>central</mirrorOf> 19 <name>Human Readable Name for this Mirror.</name> 20 <url>http://mirrors.ibiblio.org/pub/mirrors/maven2/</url> 21 </mirror> 22 23 <mirror> 24 <id>jboss-public-repository-group</id> 25 <mirrorOf>central</mirrorOf> 26 <name>JBoss Public Repository Group</name> 27 <url>http://repository.jboss.org/nexus/content/groups/public</url> 28 </mirror> 29 30 <mirror> 31 <id>JBossJBPM</id> 32 <mirrorOf>central</mirrorOf> 33 <name>JBossJBPM Repository</name> 34 <url>https://repository.jboss.org/nexus/content/repositories/releases/</url> 35 </mirror>
上面的仓库经过测试是可以访问的。
6.仓库搜索服务地址
Sonatype Nexus：https://repository.sonatype.org/
MVNrepository：http://mvnrepository.com/
关于依赖的搜索，个人觉得这两个是最好用的。
