《Maven 实战》读书笔记（四） 仓库

本文主要是介绍《Maven 实战》读书笔记（四） 仓库，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

0.1. 仓库的概念

大家可能注意到了，在基于Maven管理的项目开发中，这个项目自身是不引进第三方jar包的，使用的时候通过pom.xml的依赖机制，从本地仓库或者远程仓库去获取第三方jar包。这个其实是打破了以往的开发习惯，一般我们是在开发项目的时候需要哪个jar包了，立刻google一下，找到相关网址，之后下载，放到我们项目的classpath中。现在是不必强制引用jar，只要通过pom.xml配置，到一定的时刻，比如编译、测试、打包、部署，自然会将依赖的jar放进您预先的位置。Maven仓库是基于简单文件系统存储的，根据咱们之前提到的坐标，可以找到该组件在仓库的位置。

0.2. 仓库的分类

一般说Maven的仓库就是指2个类型，一个就是我们自己的PC机器本地仓库，另一个就是指远程的Maven中心仓库（天啊，如果某天Maven组织宣布不对中国开放中心仓库那是怎样的局面啊？我的妈呀，太刺激啦~）。当本地仓库没有您需要的jar包的时候，它会从远程核心中心仓库中下载，所以说美国人想制约咱们中国的软件发展是很容易的，现在搞得连仓库都云计算、云存储了，真要是中美打起仗来……。不过我们有私服，私服就是另一种特殊的远程仓库，为了节省Maven核心仓库的带宽和时间，很多企业都在公司的局域网内搭建了私有的仓库服务器，内部项目先从私服下载东东，没有的时候私服从外网中心仓库下载，内部开发的项目还能上传到私服上供其他项目组使用。

0.3. 本地仓库明细

本地仓库大家已经不陌生了，默认是在用户临时文件夹的~/.m2/repository下。

settings.xml中


1. Maven仓库依赖解析机制

当本地仓库没有依赖组件的时候，Maven会从远程的中心仓库或者私服下载依赖包，当依赖的版本是快照版本的时候，则自动先找到快照的最新版本。

1.1：当依赖范围是system的时候，Maven直接从本地库解析

1.2：根据咱们之前提到的Maven坐标解析路径后，开始查找工作，如果根据坐标发现了该组件，那么认为此次解析依赖成功

2.1：当本地仓库不存在相应组件的情况下，如果在pom.xml写着以来的版本是显示的发布版本，例如

    <dependency>  
        <groupId>javax.mail</groupId>  
        <artifactId>mail</artifactId>  
        <version>1.4.1</version>  
    </dependency> 

就是要javax.mail.jar.1.4.1版本，遍历远程仓库，如果在远程仓库发现了精确版本，下载。

2.2.1：如果在pom.xml文件中依赖写着的版本是基于更新策略（RELEASE或者LATEST）读取远程仓库元数据，将远程元数据的版本与本地仓库元数据仓库对应合并后，计算出版本真实值，然后基于这个真实的值检查本地和远程仓库。重复1.1和1.2步骤。

2.2.2：如果pom文件中依赖的版本是快照版本SNAPSHOP版本，则读取远程仓库的元数据，将其与本地仓库元数据进行对比，合并，得到一个快照版本值，之后看哪个比较新，从相应的库下载（一般都是远程仓库比本地的新，基本不可能本地的比远程的仓库版本还新吧，除非是该组件的原作者）

2.2.3：如果最后解析出来的版本是时间戳，会将其替换成快照格式。
从而可以看出，当依赖版本很“暧昧”的时候——RELEASE、LATEST、SNAPSHOP，Maven需要将本地仓库和远程仓库进行对比，本地库与远程库要进行合并、更新。与此有关的配置是releases、snapshots，只有开启了相关配置，才能访问仓库的发布版本信息。

    <repositories>  
        <repository>  
            <id>jboss</id>  
            <url>http://repository.jboss.com/maven2/</url>  
            <releases>  
                <enabled>true</enabled>  
            </releases>  
            <snapshots>  
                <enabled>false</enabled>  
            </snapshots>  
            <layout>default</layout>  
        </repository>  
    </repositories>  

RELEASE：代表最新发布版本（发布的意思就是较为稳定，经过测试）

LATEST：代表最新版本（包含快照版本）

<?xml version="1.0" encoding="UTF-8"?><metadata>  
  <groupId>org.icefaces</groupId>  
  <artifactId>icefaces-comps</artifactId>  
  <version>1.6.1</version>  
  <versioning>  
    <versions>  
      <version>1.6.1</version>  
      <version>1.6.2</version>  
      <version>1.7.0</version>  
      <version>1.7.1</version>  
      <version>1.7.2</version>  
      <version>1.8.0</version>  
    </versions>  
    <lastUpdated>20110602022501</lastUpdated>  
  </versioning>  
</metadata> 

    <?xml version="1.0" encoding="UTF-8"?><metadata>  
      <groupId>org.eclipse.persistence</groupId>  
      <artifactId>eclipselink</artifactId>  
      <version>1.0.2</version>  
      <versioning>  
        <versions>  
          <version>1.0.2</version>  
        </versions>  
        <lastUpdated>20110602022437</lastUpdated>  
      </versioning>  
    </metadata>  

需要注意的是，这种暧昧的版本在Maven中不太推荐，有可能今天构建成功了，明天第三方组织发布了一个快照版本，接口全变了，那就构建失败了。所以别搞暧昧，需要什么版本，大大方方的提出来即可。

2. Maven插件解析机制

本节复习前文背景是：http://suhuanzheng7784877.iteye.com/blog/1069257

我们使用Maven插件的目标的时候都是利用他的前缀（简写），一旦执行命令出问题了，比较难定位具体是哪个插件运行出错的。在此咱们一起来看看它的插件插件机制。为何将仓库的依赖解析和插件解析放在一起呢，因为他们确实有相似的地方。插件的组件也是基于坐标存在于Maven库中，需要的时候，从本地仓库需要相关插件，不存在，从远程仓库去找，找到后下载到本地。当然了区别于依赖的是插件的远程库必须显示的在pom文件中配置，不配置，不会去远程下载。

    <pluginRepositories>  
        <pluginRepository>  
            <id>central</id>  
            <name>Maven plugin</name>  
            <url>htpp://repo1.maven.org/maven2</url>  
            <layout>default</layout>  
            <snapshots>  
                <enabled>true</enabled>  
            </snapshots>  
            <releases>  
                <enabled>false</enabled>  
            </releases>  
        </pluginRepository>  
    </pluginRepositories>  

这个和依赖库的配置意思差不多打开快照版本插件，如果自己写了Maven插件，可以参考上面的配置。使用插件时，默认的groupId的值是org.apache.maven.plugins，是官方apache标准插件。

    <build>  
        <plugins>  
            <plugin>  
                <groupId>org.apache.maven.plugins</groupId>  
                <artifactId>maven-shade-plugin</artifactId>  
                <executions>  
                    <execution>  
                        <phase>package</phase>  
                        <goals>  
                            <goal>shade</goal>  
                        </goals>  
                        <configuration>  
                            <transformers  
                                implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">  
                                <mainClass>com.liuyan.maven.helloword.HelloWorld</mainClass>  

                            </transformers>  
                        </configuration>  
                    </execution>  
                </executions>  
            </plugin>  
        </plugins>  
    </build>  

<groupId>org.apache.maven.plugins</groupId>其实可以省略。

使用插件的版本解析和仓库依赖组件的解析一样，先从本地解析，寻找。没有了从配置仓库查找。同样建议别使用“暧昧”版本插件。

至于插件的前缀解析机制，可以参看插件元数据

Windows7平台：C:\Users\用户名\.m2\repository\org\apache\maven\plugins下面的maven-metadata-central.xml文件描述了大多数常用的插件信息、以及前缀简写信息。使用——简写插件：目标后Maven会根据简写找到具体的插件全名，之后根据插件的当前元数据groupId，之后在找到版本号信息，最后就得到了完整的该插件的完整坐标。之后按照坐标去找具体实现、下载、使用之。

3. 总结

这次补充了仓库依赖和插件的解析机制，让我们更了解一些Maven的内核机制。

这篇关于《Maven 实战》读书笔记（四） 仓库的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---