Maven****的传递性和依赖性
依赖管理
- compile-默认值编译范围，默认 scope ，在工程环境的 classpath （编译环境）和打包（如果是 WAR 包，会包含在 WAR包中）时候都有效。
- provided容器或 JDK 已提供范围，表示该依赖包已经由目标容器（如 tomcat ）和 JDK 提供，只在编译的 classpath 中加载和使用，打包的时候不会包含在目标包中 。最常见的是j2ee 规范相关的 servlet-api 和 jsp-api 等 jar 包，一般由servlet 容器提供，无需在打包到 war 包中，如果不配置为 provided ，把这些包打包到工程 war包中，在 tomcat6 以上版本会出现冲突无法正常运行程序（版本不符的情况）。
- runtime一般是运行和测试环境使用，编译时候不用加入 classpath ，打包时候会打包到目标包中。一般是通过动 态加载或接口反射加载的情况比较多。也就是说程序只使用了接口，具体的时候可能有多个，运行时通过配置文件或jar 包扫描动态加载的情况。典型的包括： JDBC 驱动等。
- test测试范围，一般是单元测试场景使用，在编译环境加入classpath，但打包时不会加入，如junit等。
- system（一般不用，不同机器可能不兼容）
系统范围，与 provided 类似，只是标记为该 scope 的依赖包需要明确指定基于文件系统的 jar 包路径。因 为需要通过systemPath 指定本地 jar 文件路径，所以该 scope 是不推荐的。如果是基于组织的，一般会建 立本地镜像，会把本地的或组织的基础组件加入本地镜像管理，避过使用该scope 的情况。
左边第一列表示第一直接依赖范围
上面第一行表示第二直接依赖范围
中间的交叉单元格表示传递性依赖范围。
定义在标签
总结：
(1) 当第二依赖的范围是 compile 的时候，传递性依赖的范围与第一直接依赖的范围一致。
(2) 当第二直接依赖的范围是 test 的时候，依赖不会得以传递。
(3) 当第二依赖的范围是 provided 的时候，只传递第一直接依赖范围也为 provided 的依赖，且传递性依赖的范围同样为 provided ；
(4) 当第二直接依赖的范围是 runtime 的时候，传递性依赖的范围与第一直接依赖的范围一致，但
compile 例外，此时传递的依赖范围为 runtime ；
依赖冲突
(1) 如果直接与间接依赖中包含有同一个坐标不同版本的资源依赖，以直接依赖的版本为准（就近原则）
(2) 如果直接依赖中包含有同一个坐标不同版本的资源依赖，以配置顺序下方的版本为准（就近原则）
可选依赖
true/false 用于设置是否可选，也可以理解为jar包是否向下传递。
在依赖中添加 optional 选项决定此依赖是否向下传递，如果是 true 则不传递，如果是 false 就传递，默认为false 。
排除依赖
在直接依赖的配置里面添加 exclusions → exclusion 元素，指定要排除依赖的 groupId 和 artifactId 就行，如下面代码所示。
说明:排除依赖包中所包含的依赖关系，不需要添加版本号。
排除前
排除后
项目中出现包名和类名一样的时候。如果idea 项目project structure 可以调整依赖jar的顺序，把需要使用的jar 放到最前面即可
