一、依赖范围
Maven在编译项目主代码的时候，需要使用一套classpath——编译classpath；
在编译和执行测试的时候，使用另一套classpath——测试classpath；
实际运行Maven项目的时候，又会使用一套classpath——运行classpath。
【依赖范围】就是用来控制依赖与这三种classpath的关系，Maven有以下几种依赖范围：
1、compile：编译依赖范围
默认，对编译、测试、运行三种classpath都有效，如spring-core.
2、test：测试依赖范围
只对测试classpath有效，如JUnit。
3、provided：已提供依赖范围
对编译和测试classpath有效，但对运行时无效，如Tomcat容器的servlet-api，编译和测试项目需要，但运行项目时，容器已经提供。
4、runtime：运行时依赖范围
对于测试和运行classpath有效，但在编译主代码时无效，如JDBC驱动实现，项目主代码的编译只需要JDK提供的JDBC接口，只有在执行测试或运行时才需要实现上述接口的具体JDBC驱动。
5、system：系统依赖范围
该依赖于三种classpath的关系，和provided依赖范围完全一致，但往往与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使用。
6、import：导入依赖范围
该依赖范围不会对三种classpath产生实际的影响。
二、传递性依赖
如图，若A有一个compile范围的依赖B，B有一个compile范围的依赖C，那么C就会成为A的compile范围依赖。
C是A的一个传递性依赖。
若：
A对于B是第一直接依赖；
B对于C是第二直接依赖；
A对于C是传递性依赖；
则：
其中，左一列是第一直接依赖范围，上一行是第二直接依赖范围，中间就是传递性依赖的范围。
三、可选依赖
使用optional元素表示两个依赖为可选依赖，它们只会对B产生影响，当其他项目依赖于B的时候，这两个依赖不会被传递，就需要在A中显示地声明出来mysql-connector-java、或postgresql。
在理想的情况下，是不应该使用可选依赖的！！
四、排除依赖
项目A依赖于项目B，但是由于一些原因，不想引入传递性依赖C，而是自己显示地声明对于项目C的版本依赖，可在代码中使用exclusions元素声明排除依赖。exclusions可以包含一个或者多个exclusion子元素，且exclusion只需要groupId和artifactId。
五、归类依赖
例如，对Spring Framework的依赖来自同一项目的不同模块，所有这些依赖的版本都是相同的，如果将来需要升级Spring Framework，这些依赖的版本会一起升级。
六、优化依赖
dependency:list
dependency:tree
dependecy:analyze