系统学习maven——（4）从仓库解析maven的依赖机制

当Maven根据坐标寻找构件的时候，它首先会查看本地仓库，如果本地仓库存在此构件，则直接使用;如果本地仓库不存在此构件，或者需要查看是否有更新的构件版本，Maven 就会去远程仓库查找，发现需要的构件之后，下载到本地仓库再使用。如果本地仓库和远程仓库都没有需要的构件,Maven就会报错。这背后的依赖解析机制可以概括如下:

      1)当依赖的范围是system的时候，Maven 先直接从本地文件系统解析构件。

      2)根据依赖坐标计算仓库路径后，尝试直接从本地仓库寻找构件，如果发现相应构件，则解析成功。

      3)在本地仓库不存在相应构件的情况下，如果依赖的版本是显式的发布版本构件，如1.2、2. 1-beta-1等，则遍历所有的远程仓库，发现后，下载并解析使用。

      4)如果依赖的版本是RELEASE或者LATEST,则基于更新策略读取所有远程仓库的元数据groupld/ artifactld maven-metadata. xml,将其与本地仓库的对应元数据合并后，计算出RELEASE 或者LATEST真实的值，然后基于这个真实的值检查本地和远程仓库,如步骤2)和3)。

      5)如果依赖的版本是SNAPSHOT,则基于更新策略读取所有远程仓库的元数据groupId/ arifactId/version/maven-metadata. xml,将其与本地仓库的对应元数据合并后，得到最新快照版本的值，然后基于该值检查本地仓库，或者从远程仓库下载。

      6)如果最后解析得到的构件版本是时间戳格式的快照，如1. 4. 1-20091104.121450-121,则复制其时间戳格式的文件至非时间戳格式，如SNAPSHOT,并使用该非时间戳格式的构件。

        7)当Maven检查完更新策略，并决定检查依赖更新的时候，就需要检查仓库元数据：maven-metadata.xml

(需要注意的是，在依赖声明中使用LATEST和RELEASE是不推荐的做法，因为Maven随时都可能解析到不同的构件，且Maven不会明确告诉用户这样的变化。当这种变化造成构建失败的时候，发现问题会变得比较困难。RELEASE 因为对应的是最新发布版构建，还相对可靠，LATEST (对应最新的版本)就非常不可靠了，为此，Maven 3不再支持在插件配置中使用LATEST和RELEASE。如果不设置插件版本，其效果就和RELEASE一样，Maven 只会解析最新的发布版本构件。不过即使这样，也还存在潜在的问题。例如，某个依赖的1.1版本与1.2版本可能发生.些接口的变化，从而导致当前Maven构建的失败。)

参考至《maven实战》