依赖的作用域范围

元素的取值有compile，provided，runtime，test，system，import

provided的一个应用场景：

maven的依赖传递，在多个传递下同一个jar包的版本不同，可能会导致包冲突等一系列问题。解决这个冲突有两种方案：

 1. 在依赖方进行排除
 2. 在提供方将依赖的范围定义为不传递provided和true

比如项目中使用热部署工件spring-boot-devtools，就可以使用optional元素来进行定义，对应pom文件中配置如下：

<dependency>
    <groupId>org.springframework.bootgroupId>
    <artifactId>spring-boot-devtoolsartifactId>
    <optional>trueoptional>
dependency>

 optional元素设置为true，表示该依赖不在项目之间传递。

假如有两个项目A和B，其中A为父项目，B为子项目。在父项目中引入junit依赖，此时子项目打包会包含junit的jar包

scope provided(已提供)，可以理解为此包不由“我”提供，需要依赖方/容器提供。provided不会被打包，也不具有传递性。比如spring-boot-devtools、servlet-api等，前者是因为不需要在生产中热部署，后者是因为容器已经提供，不需要重复引入。

scope test，表示被依赖项仅参与测试。常见的单元测试junit

<dependency>
    <groupId>junitgroupId>
    <artifactId>junitartifactId>
    <version>4.12version>
    <scope>testscope>
dependency>

类似单元测试这样的依赖，如果不设置scope为test，很显然它们会被打包发布，但在生产环境中并没什么用。

runtime仅用于运行和测试环节，在编译环境下不会被使用。比如编译时只需要JDBC API的jar，而只有运行时才需要JDBC驱动实现。

<dependency>
    <groupId>mysqlgroupId>
    <artifactId>mysql-connector-javaartifactId>
    <version>8.0.20version>
    <scope>runtimescope>
dependency>

system标记的被依赖项不会从maven仓库获取，而需要本地文件系统提供。使用时，一定要配合属性。不推荐使用，尽量从maven仓库中获取。

其中B依赖A，C依赖B，传递性的关键是B依赖A时所设置的scope值，当B采用不同的值时对应的依赖关系如下：当B通过test或provided依赖A时，C不依赖A；当B通过runtime或compile依赖A时，C依赖A；