2.Maven仓库

【什么是maven仓库】

Maven可以在某个位置统一存储所有Maven项目共享的构件，这个统一的位置就是仓库。

【仓库分类】

仓库只分两类：本地仓库和远程仓库。当Maven根据坐标寻找构件时，首先会查看本地仓库，如果本地仓库存在此构件则使用；如果不存在，maven就会去远程仓库找，发现需要的构件之后，下载到本地仓库再使用

【特殊仓库】

中央仓库是Maven核心自带的远程仓库，它包含了绝大部分开源构件。
私服是另一种特殊的远程仓库，为了节省带宽和时间，应该在局域网内，架设一个私有的仓库服务器，用其代理所有外部远程仓库，内部项目还可以部署到私服上供其他项目使用。
其他公开远程仓库

【本地仓库】

(Windows)默认位置：C:/Users/LIC/.m2/repository（LIC为系统当前登录用户）
(Linux)默认位置: /home/lic/.m2/repository
编辑setting.xml可以改变本地仓库位置

【中央仓库】

    
        central 
        Maven Repository Switchboard
        http://repo1.maven.org/maven2 
        default
        
            false
        
    

由于最原始的本地仓库是空的，Maven必须知道至少一个可用的远程仓库，才能在执行Maven命令时下载到需要的构件。中央仓库就是这样默认的一个仓库，它包含了绝大多数流行的开源java构件，以及源码、作者信息、SCM、许可证信息等。

【私服】

私服是一种特殊的远程仓库，它是架设在局域网内的仓库服务，私服代理广域网上的远程仓库，供局域网内maven用户使用。

私服的优点：节省外网带宽、加速maven构建、部署第三方构建、提高稳定性、降低中央仓库的负荷

【远程仓库配置】

    
        jboss 
        Jboss Repository
        http://repository.jboss.com/maven2 
        default
        
            daily
            ignore
            true
        
        
            false
        
    


在repositories元素下，可以声明一个或多个repository。任何仓库声明的id必须是唯一的，
尤其需要注意的是，Maven自带中央仓库使用的id是central，如果其他的仓库声明也使用该id，就会覆盖中央仓库的位置。
该配置中release和snapshots元素比较重要，它们用来控制Maven对于发布构件和快照版构件的下载。
元素updatePolicy用来配置Maven从远程仓库检查更新的频率，默认是daily（每天）、never（从不检查更新）
、always（每次构建都检查）、interval X（每隔X分钟检查一次更新）

【远程仓库认证】

    
        
            my-proj
            repo-user
            repo-pwd
        
    


配置认证信息和配置仓库信息不同，仓库信息可以直接配置在pom文件中，但是认证信息必须配置在setting.xml文件中。
这是因为pom往往被提交到代码库中供所有成员访问的，而setting.xml一般只放在本机中。因此在setting.xml中配置
信息更安全。
setting.xml中server元素的id必须与POM中需要认证的repository元素的id完全一致。

【部署至远程仓库】

Maven除了能对项目进行编译、测试、打包之外，还能将项目生成的构建部署到仓库中。首先需要编辑项目的pom.xml文件，配置distributionManagement元素。
distributionManagement包含repository和snapshotRepository子元素，前者表示发布版本构件的仓库，后者表示快照版本的仓库。

往远程仓库部署构件的时候，往往需要认证。配置认证的方式，就是需要在setting.xml中创建一个server元素，
其id与仓库id匹配，并配置正确的认证信息


    ...
    
        
            proj-release
            Proj release Repository
            http://192.168.1.35/content/repositories/proj-releases 
        
        
            proj-snapshots
            Proj Snapshot Repository
            http://192.168.1.35/content/repositories/proj-snapshots 
        
    

【从仓库解析依赖机制】

1)当依赖的范围是system的时候Maven直接从本地文件系统解析构件
2)根据依赖坐标计算仓库路径后，尝试直接从本地仓库寻找构件，如果发现相应构件，则解析成功。
3)在本地仓库不存在相应构件的情况下，如果依赖的版本是显式的发布版本构件，如1.2、21-beta-1等，则遍历所有的远程仓库，发现后，下载并解析使用。
4)如果依赖的版本是RELEASE或者LATEST，则基于更新策略读取所有远库的元数据groupld/artifactId/maven-metadataxml将其与本地仓库的对应元数据合并后计算出RELEASF或者LATEST真实的值，然后基于这个真实的值检查本地和远程仓库，如2)和3)。
5)如果依赖的版本是SNAPSHOT，则基于更新策略读取所有远程仓库的元数据groupId/artifactId/version/maven-metadataxml，将其与本地仓库的对应元数据合并后，得到最新快照版本的值，然后基于该值检查本地仓库，或者从远程仓库下载。
6)如果最后解析得到的构件版本是时间戳格式的快照，如14.1-20091104121450-121则复制其时间戳格式的文件至非时间截格式，如SNAPSHOT，并使用该非时间戳格式的构件。当依赖的版本不明晰的时候，如RELEASE、LATEST和SNAPSHOT，Maven就需要基于更新远程仓库的更新策略来检查更新。在第6.4节提到的仓库配置中，有一些配置与此有关首先是和，只有仓库开启了对于发布版本的支持时，才能访问该仓库的发布版本构件信息，对于快照版本也是同理;其次要注意的是和的子元素，该元素配置了检查更新的频率，每日检查更新、永远检查更新、从不检查更新、自定义时间间隔检查更新等。最后，用户还可以从命令行加人参数-U强制检查更新，使用参数后，Maven就会忽略的配置当Maven检查完更新策略，并决定检查依赖更新的时候，就需要检查仓库元数据maven-metadata.xml

【maven-metadata.xml】

    org.sonatype.nexus
    nexus
    
        1.4.2-SNAPSHOT 
        1.4.0 
        
            1.3.5 < /version >
            1.3.6 < /version >
            1.4.0-SNAPSHOT < /version >
            1.4.0
            1.4.0.1-SNAPSHOT < /version >
            1.4.1-SNAPSHOT < /version >
            1.4.2-SNAPSHOT < /version >
        
        20091214221557
    < /versioning >
< /metadata >
该XML文件列出了仓库中存在的该构件所有可用的版本，
同时 latest 元素指向了这些版本中最新的那个版本，该例中是1.4.2-SNAPSHOT。
而release 元素指向了这些版本中最新的发布版本，该例中是1.4.0。
Maven 通过合并多个远程仓库及本地仓库的元数据，就能计算出基于所有仓库的 latest 和 release 分别是什么，
然后再解析具体的构件。需要注意的是，在依赖声明中使用 LATEST和RELEASE是不推荐的做法因为 Maven 随时都可能解析到不同的构件，可能今天 LATEST 是1.3.6明天就成为 14.0-SNAPSHOT 了，
Maven 不会明确告诉用户这样的变化。当这种变化造成构建失败的时候，发现问题会变得比较困难。RELEASE 因为对应的是最新发布版构建，还相对可靠，LATEST 就非常不可靠了，
为此Maven 3 不再支持在插件配置中使用 LATEST 和RELEASE。如果不设置插件版本，其效果就和RELEASE--样，Maven 只会解析最新的发布版本构件。
不过即使这样，也还存在潜在的问题例如某个依赖的1.1 版本与1.2 版本可能发生一些接口的变化，从而导致当前 Maven 构建的失败当依赖的版本设为快照版本的时候，Maven 也需要检查更新，这时，Maven 会检查仓库元数据groupId/artifactId/version/maven-metadataxml

【镜像】

如果仓库X可以提供仓库Y存储的所有内容，那么就可以认为X是Y的一个镜像。举个例子，http://maven.net.cn/content/groups/public/ 是中央仓库 http://repol.maven.org/maven2/ 在中国的镜像，由于地理位置的因素，该镜像往往能够提供比中央仓库更快的服务。因此，可以配置 Maven 使用该镜像来替代中央仓库。 

编辑 settingsxml，新增镜像
下面的例子中，的值为central，表示该镜像为中央仓库的镜像，任何对中央仓库的请求都会转至该镜像，如果镜像需要认证，也是基于该id配置仓库认证

    ...
    
        
            maven.net.cn < /id >
            one of the central mirrors in China 
            http://maven.net.cn/content /groups/public/
            central
        < /mirror>
    < /mirrors >
    ...
< /settings >

关于镜像的一个更为常见的用法是结合私服。由于私服可以代理任何外部的公共仓库，因此可以这样配置

    ...
    
        
            internal-repo < /id >
            internal-repo
            http://192.168.1.35/content /groups/public/
            *
        < /mirror>
    < /mirrors >
    ...
< /settings >
* 匹配所有远程仓库
external:* 匹配所有远程仓库,使用localhost除外，使用file://协议的除外
repo1,repo2 匹配仓库1、匹配仓库2
*,!repo2 匹配所有远程仓库，repo2除外

【仓库搜索服务】

1.Sonatype Nexus
地址: http://repository.sonatype.org
Nexus 是当前最流行的开源 Maven 仓库管理软件，本书后面会有专门的章节讲述如何使用Nexus 假设私服。
这里要介绍的是 Sonatype 架设的一个公共Nexus 仓库实例。Nexus 提供了关键字搜索、类名搜索、坐标搜索、校验和搜索等功能。搜索后，页面清晰地列出了结果构件的坐标及所属仓库。用户可以直接下载相应构件，还可以直接复制已经根据坐标自动生成的XML依赖声明

2.Jarvana
地址:http://www.jarvana.com/jarvana/
Jarvana 提供了基于关键字、类名的搜索，构件下载、依赖声明片段等功能也一应俱全值得一提的是，Jarvana 还支持浏览构件内部的内容。此外，Jarvana 还提供了便捷的 Java 文档浏览的功能。

3.MVNbrowser
地址: http://www.mvnbrowser.com
MVNbrowser 只提供关键字搜索的功能，除了提供基于坐标的依赖声明代码片段等基功能之外，MVNbrowser 的一大特色就是，能够告诉用户该构件的依赖于其他哪些构(Dependencies)以及该构件被哪些其他构件依赖 (Referenced By)

4. MVNrepository
地址: http://mvnrepository.com/MVNrepository 的界面比较清新，它提供了基于关键字的搜索、依赖声明代码片段、构件下载、依赖与被依赖关系信息、构件所含包信息等功能。MVNrepository 还能提供一个简单的图表，显示某个构件各版本间的大小变化。