依赖是maven最为用户熟知的特性之一，单个项目的依赖管理并不难，但是要管理几个或者几十个模块的时，那这个依赖应该怎么管理
-
依赖的传递性
-
-
A 依赖 B，B 依赖 C，A 能否使用 C 呢？那要看 B 依赖 C 的范围是不是 compile，如果是则可用，否则不可用
-
-
依赖的作用范围
-
compile
-
这是默认范围，编译依赖对项目所有的classpath都可用。此外，编译依赖会传递到依赖的项目
-
-
provided
-
表示该依赖项将由JDK或者运行容器在运行时提供，也就是说由Maven提供的该依赖项我们只有在编译和测试时才会用到，而在运行时将由JDK或者运行容器提供。
-
-
runtime
-
表明编译时不需要依赖，而只在运行时依赖
-
-
test
-
只在编译测试代码和运行测试的时候需要，应用的正常运行不需要此类依赖。
-
-
system
-
系统范围与provided类似，不过你必须显式指定一个本地系统路径的JAR，此类依赖应该一直有效，Maven也不会去仓库中寻找它。
<project>
...
<dependencies>
<dependency>
<groupId>sun.jdk</groupId>
<artifactId>tools</artifactId>
<version>1.5.0</version>
<scope>system</scope>
<systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>
</dependencies>
...
</project>
-
-
import
-
范围只适用于<dependencyManagement>部分。表明指定的POM必须使用<dependencyManagement>部分的依赖。因为依赖已经被替换，所以使用import范围的依赖并不影响依赖传递。
-
-
-
依赖的两大原则
-
-
依赖的管理
-
依赖排除
-
任何可传递的依赖都可以通过 "exclusion" 元素被排除在外。举例说明，A 依赖 B， B 依赖 C，因此 A 可以标记 C 为 "被排除的"
![]()
-
-
依赖可选
-
任何可传递的依赖可以被标记为可选的，通过使用 "optional" 元素。例如：A 依赖 B， B 依赖 C。因此，B 可以标记 C 为可选的， 这样 A 就可以不再使用 C。
-
-
jar包冲突解决
命令: mvn dependency:tree -Dverbose
1.maven的jar包冲突解决（一般使用排除依赖的方式解决jar包冲突）
