一. 从仓库解析依赖的机制
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的时候使用
| 依赖范围(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