一. 从仓库解析依赖的机制

1. 依赖范围：如果构件的依赖范围为system，则直接从本地系统获取，关于依赖的范围参照：

依赖：通俗的说是jar包在哪个环节会用到（编译时，测试时，运行时）

范围：通过不同的关键字指定范围，说明jar包（或者是war包、pom包）在哪个环节用到

分类：

• compile：编译依赖，在三个环节用到该jar包，默认的
• test：测试依赖，在测试环境用到
• runtime：运行依赖，在测试和运行时用到
• provided：提供依赖，在编译和测试环境用到，因为在运行环境时，环境本身会提供相关的jar包，如果再引入就会冲突，比如在JavaEE web项目中我们需要使用servlet的API，但是tomcat中一键提供这个jar，我们在编译和测试的时候需要使用这个api，但是部署到tomcat的时候，如果还加入servlet构建就会产生冲突，这个时候可以使用provided
• system：系统以来，类似于provided，但是它要指定本地以来的jar包路口，也就是与本地系统进行了绑定，不利于转移性
• import：导入其他的POM.xml文件中的依赖，在dependencyManagement的时候使用

依赖范围与classpath的关系

依赖范围(Scope)	对于编译classpath有效	对于测试classpath有效	对于运行时classpath有效	例子
compile	Y	Y	Y	spring-core
test	-	Y	-	JUnit
provided	Y	Y	-	servlet-api
runtime	-	Y	Y	JDBC驱动实现
system	Y	Y	-	本地的，Maven仓库之外的类库文件

 

 

 

 

 

 

2. 仓库路径：根据groupId或者artifactId计算仓库路径

3. 依赖仓库：

　　(1) 本地仓库：根据第2步的仓库路径优先从本地仓库寻址构件，如果存在则解析成功

　　(2) 远程仓库：如果本地仓库查找不到，则从遍历所有的远程仓库进行查找

4. 依赖版本：

　　(1) 如果版本为发行版本（不含有关键字：RELEASE、LATEST、SNAPSHOT），比如：1.2/2.1/1-beat-1，从按照第3步的方法查找

　　(2) 如果版本为RELEASE或者LATEST（也就是版本号定义为：<version>1.0-RELEASE</version>或者<version>LATEST/version>），则根据第2步的灿烂路径获取元数据文件maven-metadata.xml文件，确定最后的RELEASE或者LATEST的值，如果maven-metadata.xml文件内容如下，则RELEASE应该是3.4.0，LATEST应该是3.5.0

<versioning>
    <latest>3.5.0</latest>      #latest：最新版本
    <release>3.4.0</release>    #release：发行版本
    <versions>
      <version>2.0-rc1</version>
      <version>2.0</version>
      <version>2.0.1</version>
      <version>2.0.2</version>
      <version>2.1.0-M1</version>
      <version>2.1.0-M2</version>
      <version>2.1.0</version>
      <version>2.2 </version>
      <version>2.2.1</version>
      <version>3.0.0 </version>
      <version>3.5.1-SNAPSHOT </version>    #SNAPSHOT：快照版本
    </versions>
    <lastUpdated>20150224022345</lastUpdated>
  </versioning>
</metadata>

　　(3) 如果版本为SNAPSHOT，按照4.2计算最新快照的版本值，然后下载构建，这里应该是3.5.1-SNAPSHOT。如果解析到的是时间戳格式，如果20091214.221414，则下载该构建，并且重新命名为1.4.2-SNAPSHOT

5. 注意：

　　(1) 构建的解析前提还是要按照配置的策略，具体参考上文远程仓库的配置

　　(2) 不推荐使用RELEASE或者LATEST，因为它是不稳定的，也有可能是SNAPSHOT，从Maven开始不支持设置RELEASE和LATEST