6.Maven依赖的基本操作
在一个工程中使用到另外的工程，此时就是一种依赖，要将被依赖的坐标写道配置文件中，
<dependencies>标签的子标签<dependency></dependency>说明当前项目依赖坐标对应的项目，在编译时，就会去本地中查找，所以还要将被依赖的工程安装进入仓库mvn istall★★★1. 依赖范围： 设置在< scope >标签中
1.compile：对于主程序是有效的，对于测试程序也是有效的（测试程序是基于主程序的），并且参与打包
2. test：仅仅对测试程序有效，并且不参与打包
3. provided：对主程序测试程序都有效，但是不参与打包（不参与部署）
掌握并理解依赖范围最重要的是解决jar 包可能出现的冲突
compile依赖范围的jar 包是在整个web 工程过程中都需要的。provided 依赖在开发过程需要，
但是在部署运行时不再需要依赖的jar 包，因为所需要的jar 包，
在tomcat 上都有jar 包的重复加载反而会出现错误2.依赖的传递性
可以传递的依赖不必在每个模块工程中都重复的声明，在最底层的工程中依赖一次即可。只有compile 范围的依赖可以传递。不能传递的依赖在那里用就在那里加上
3.依赖的排除
当前的项目不需要他依赖的项目中传递过来的jar 包，就要将它排除
配置依赖的标签下配置，标签<exclusion>配置grounpid artifact 两个标签</exclusion>4.依赖原则
路径最短优先，路径一样时声明优先（生命是指：dependecy 标签的声明顺序）
5.依赖的继承
问题： 项目1中junit版本4.0 /项目2中junit 版本4.0 /项目3中junit 版本4.9.由于test 范围的以来不能传递，所以会分散在各个工作模块中，导致版本不一致
需求： 统一管理各个模块中的junit 的版本
解决：
将junit 以来统一到“父”工程中，在子工程中声明junit 依赖是不指定版本，以符工程中统一的设定为准，同时也便于修改
步骤：
- 创建一个Maven工程作为父工程，打包方式为pom
- 在子工程中声明对父工程的引用
- 将子工程的坐标与父工程坐标中重复的内容删除
- 在父工程中同意junit 的依赖
- 在子工程中删除junit 依赖的版本号部分
依赖的继承这种设计可以结合依赖导致原则来理解：上层不依赖下层，他们共同依赖一个抽象；抽象不依赖具象，具象依赖抽象
同时在代码中应该尽量的减少依赖（降低耦合度），依赖越简单系统就越稳定。所有依赖junit 的模块共同依赖一个fu工程就减少了依赖的复杂度
聚合： 一键安装多个模块聚合：一键安装多个模块
