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工程就减少了依赖的复杂度
聚合: 一键安装多个模块聚合:一键安装多个模块
如何向maven 项目中导入依赖:https://mp.csdn.net/mdeditor/88201502