一：依赖范围
Maven在编译项目主代码的时候需要使用一套classpath。其次，在编译和执行测试的时候会使用另外一套classpath。最后，实际运行Maven项目的时候，又会使用一套classpath。
所谓的依赖范围就是用来控制依赖与这三种classpath（编译、测试、运行）的关系，Maven有以下几种依赖范围：
- compile：编译依赖范围。如果没有指定，默认使用该依赖范围。使用此依赖范围时，对于编译、测试、运行都有效。例如：spring-core，编译、测试、运行时都需要使用该依赖。
- test：测试依赖范围。只对测试classpath有效。例如：JUnit，它只在编译测试代码以及运行测试的时候才需要，编译和运行classpath时无法使用此依赖。
- provided：已提供依赖范围。对于编译和测试时有效，但在运行时无效。例如：servlet-api，编译和测试项目的时候需要该依赖，但运行时，由于容器已经提供，就不需要Maven重复的引入。
- runtime：运行时依赖。编译时无效，对于测试和运行有效。例如：JDBC驱动实现，编译时只需要JDK提供的JDBC接口，只有在执行测试和运行时才需要实现上述接口的具体JDBC驱动。
- system：系统依赖范围。同provided。使用该依赖时必须通过systemPath元素显式地指定依赖文件路径。主要用于依赖本地的、且Maven仓库之外的类库文件。例如：
<dependency>
<groupId>javax.sql</groupId>
<artifactId>jdbc-stdext</artifactId>
<version>2.5</version>
<scope>system</scope>
<systemPath>${spath}/lib/test.jar<systemPath>
</dependency>
二：传递依赖和依赖范围
当我们依赖一个a.jar时，如果a.jar依赖b.jar，那么只需要早pom中声明对a.jar的依赖即可，b.jar会被Maven自动加载进来。
例如：有一个org.springframework:spring-core:2.5.6的依赖，而实际上spring-core也有它自己的依赖，它依赖commons-logging。有了传递依赖机制，在使用spring-core时不需要考虑它依赖了什么。Maven会自动解析。
依赖范围在传递依赖时会略有变化
当第二直接依赖的范围是compile的时候，传递性依赖的范围与第一直接依赖的范围一致；
当第二直接依赖的范围是test的时候，依赖不会得以传递；
当第二直接依赖的范围是provided的时候，只传递第一直接依赖范围也为provi的依赖，且范围为provided；
当第二直接依赖的范围是runtime的时候，传递性的依赖范围与第一直接依赖的范围一致，但compile例外，此时传递依赖范围为runtime；
三：依赖调解
- 原则一：路径最近者优先。例如：A ->B ->C ->X(1.0) 同时 A ->D ->X(2.0)，很显然X(2.0)路径更短，会被解析使用。
- 原则二：第一声明者优先。在依赖长度相等情况下，解析在pom中依赖声明中顺序考前的。例如：A ->B ->X(1.0) 同时 A ->D ->X(2.0)。如果B在D之前声明，那么X(1.0)会被解析。
除以上两种原则外，还可以手动排除，例如：A ->B ->X(1.0)同时A ->X(2.0)。如果项目A希望加载X(2.0)可做如下声明，通过<exclusion>元素来显式排除。
<dependency> <groupId>com.xxx.xx</groupId> <artifactId>xx-B</artifactId> <version>2.5</version> <exclusions> <exclusion> <groupId>com.xx</groupId> <artifactId>project-X</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>com.xxx.xx</groupId> <artifactId>project-x</artifactId> <version>2.0</version> </dependency>
四：可选依赖
例如：b.jar是一个持久层工具包，它同时支持Mysql和PostgreSql，A项目依赖b.jar，那么在构建A时需要这两种数据库的驱动程序，但在使用的时候知会依赖一种数据库。A项目的依赖声明如下：
<dependency>
<groupId>com.xxx.xx</groupId>
<artifactId>xx.db</artifactId>
<version>2.5</version>
<dependencies>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.10</version>
<optional>true</optional>
</dependency>
<dependency>
<groupId>postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>8.4-701.jdbc3</version>
<optional>true</optional>
</dependency>
</dependencies>
</dependency>
使用<optional>元素表示这两个为可选依赖，这是依赖不会传递到A项目，当A项目需要使用基于MySQL数据库时，需要显式声明对mysql的依赖。
另外：在理想的情况下是不会出现这种情况的，因为在面向对象设计中，有一个单一职责原则，即一个jar的职责应该只有一个。所以对于b.jar，最好是创建2个Maven项目，分别实现mysql和postgresql。
五：依赖优化
代码需要不断重构才能达到最优，依赖管理也是一样，需要不断的进行去除多余依赖，以及显式的声明某些必要的依赖。
Maven会自动解析所有项目的直接依赖和传递依赖，并根据规则判断每个依赖的范围，对于一些依赖冲突也能进行调节，这些工作之后得到这个项目的完整的已解析依赖。
可通过运行以下命令查看当前项目的已解析依赖：
mvn dependency:list
上图展示了当前项目中所有已解析的依赖，同时每个依赖的范围也得以明确标示。
如果将直接在pom中声明的依赖定义为第一层依赖，这些顶层依赖的依赖定义为第二层依赖，则以此类推可以形成一个完整的依赖树。
可运行以下明细查看当前项目的依赖树
mvn dependency:tree
从上图中可以清晰看出，虽然没有声明slf4j-api，但它通过传递依赖被加载进来，其范围为compile。
可运行以下命令对当前项目依赖进行简单分析
上图中Used undeclared dependencies，表示项目中使用到的，但是没有显式声明的依赖。可以看到第一个依赖是SNAPSHOT版本，它是通过传递依赖被加载进来的，这种依赖就是项目中的隐藏的、潜在的炸弹，因为引用的是SNAPSHOT非稳定版本，且不在pom中显式声明，很容易被忽略。该炸弹一旦爆炸，往往需要耗费大量时间来查明。
还有一个Unused declared dependencies，表示项目中未使用的，但是显式声明的依赖。如果真的不需要，建议去除声明。但需要注意的是，dependency:analyze知会分析编译和测试时需要用到的依赖，一些运行时依赖就无法被发现。所以在优化依赖时一定要小心测试。
