转:[https://blog.csdn.net/u014297148/article/details/79935428](https://blog.csdn.net/u014297148/article/details/79935428)
## 1.依赖范围
依赖包参与范围:编译、测试、打包、安装、部署
想必大家在maven的pom.xml文件中 定义依赖 除了 groupId ,artifactId,version三个必要的标签外,还见过 另外一个标签scope(如下)。没错这个标签就是我下面要说的依赖范围。
```
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
</dependencies>
```
其实maven中的依赖范围有很多种,但是我们常用的只有以下三种,我们掌握这三种就够用了。他们分别是 **compile (编译)范围**依赖,**test(测试)依赖**,**provided依赖**。那问题来了我们在定义依赖的时候 这个scope 该怎么填呢?我们先讲一下判定规则:
![](https://img.kancloud.cn/25/83/25838f62b8d0dfd059fe0f0efd50a8fc_1006x165.png)
1. 是否对main主程序有效(写代码时)
2. 是否对test测试程序有效(写测试程序时)
3. 是否参与打包(package或install)
4. 是否参与部署(deploy)
其实可以把这三个依赖分为两种情况
针对程序结构(分主程序和测试程序)的依赖
我们在前面就讲过 maven project 遵循着一定目录结构
![](https://box.kancloud.cn/55252a2a9857b385553f5c443e2219e2_567x160.png)
**1.complie**
**complie 编译范围的依赖** (默认,典型例子 spring-core 对main和test都有效,参与打包参与部署)
```
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.2.6.RELEASE</version>
</dependency>
```
![](https://box.kancloud.cn/d5fd618a279ca7e929772433b94894b9_391x242.png)
**2.test**
**test 测试范围的依赖** (典型例子junit 只对test有效,不参与打包参与部署)
```
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
```
**3.provided**
针对开发过程的依赖
provided 范围的依赖(典型例子servlet-api 在开发过程中必须提供(添加tomcat运行时环境/添加maven依赖),打包过程中忽略,运行时有servlet容器提供)
参与编译与测试,不参与打包与部署(打成jar包时,不包含此依赖),如@ConditionOnClass注解,编译时可以通过
```
<dependency>
<groupId>org.apache.tomcat</groupId>
<artifactId>servlet-api</artifactId>
<version>6.0.32</version>
</dependency>
```
![](https://box.kancloud.cn/7cec63df5a48e834f630ee240016ddf3_539x234.png)
## 2.依赖传递
为了证明依赖会传递我分别建了一个A模块 依赖junit 和spring-core;B模块依赖junit和A模块如下:
![](https://box.kancloud.cn/4e318fff18811c4157b21fa956e3f7b6_605x571.png)
![](https://box.kancloud.cn/c7914a859aaa299e013b211106ed2388_640x539.png)
我们用idea的依赖树来看下 A模块,B模块这两个模块的依赖关系树:
先是A模块的 dependency tree
![](https://box.kancloud.cn/d23d468067acfd3d42aa0dfb8fecb6bc_1011x409.png)
再是B模块的关系树 dependcy tree
![](https://box.kancloud.cn/5ea30eb8d9f02899cde80a95ebf16f4c_1010x406.png)
从B的pom.xml 代码中,我们可以看出 B模块在pom.xml文件中并没有直接的配置Spring-core的依赖,但是从B的依赖关系树种我们可以看出B也依赖了spring-core,只是这个依赖关系是因为 A依赖了spring-core ,而B又依赖了A所以 B也间接的依赖了spring-core因此可以得出一个结论:
依赖可以相互之间传递
3.依赖排除
在某些情况下我们可能需要依赖某个a.jar,但又不想间接依赖这个a.jar所依赖的jar包,这时我们可以采用exclusion 来排除某个依赖。 如下:
```
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.2.6.RELEASE</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
```
4.依赖原则
我们在工作中的项目都是分模块的,而且模块之间又互相依赖,这个时候我们可能会引入相同的依赖 ,这时maven取那个依赖呢?这就是maven依赖的原则:
路径不同间接依赖中maven采用的是路径最短者优先
路径相同间接依赖中maven 采用的是依赖定义顺序从上到下
我们可以通过以下来验证这两个依赖原则的正确性,定义一个A模块分别依赖junit 与spring-core-4.2.7; 定义一个B模块 依赖与junit与A模块 与spring-core-4.3.7;定义一个C模块分别依赖junit与B;定义一个D模块 分别依赖A模块与C模块。然后根据
C模块与D模块最后依赖的spring-core的版本来验证上述两个依赖原则。
A模块
![](https://box.kancloud.cn/856d69ddf30c257294b5c71f555af494_984x521.png)
B模块
![](https://box.kancloud.cn/a3cc64b5b5b6b180301e1f80652f4962_995x571.png)
C模块
![](https://box.kancloud.cn/39989ef708918f22d2c4dbbcf8f34c62_989x505.png)
根据C模块的依赖关系树 如下
![](https://box.kancloud.cn/38c5914273e7ebdf8d1932a53b6942c1_1081x444.png)
D模块则分两种情况:
1.B模块先定义与
```
<dependencies>
<dependency>
<groupId>com.javxuam.maven</groupId>
<artifactId>B</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>com.javxuam.maven</groupId>
<artifactId>A</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
```
![](https://box.kancloud.cn/07652b295f562e32bdb720176b1834b3_1105x368.png)
A依赖定义优先B依赖
```
<dependencies>
<dependency>
<groupId>com.javxuam.maven</groupId>
<artifactId>A</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>com.javxuam.maven</groupId>
<artifactId>B</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
```
![](https://box.kancloud.cn/2ed0fe5c12ed4f07cc774d7534681802_1098x407.png)
- 计算机网络
- 基础_01
- tcp/ip
- http转https
- Let's Encrypt免费ssl证书(基于haproxy负载)
- what's the http?
- 网关
- 网络IO
- http
- 工具
- Git
- 初始本地仓库并上传
- git保存密码
- Gitflow
- maven
- 1.生命周期命令
- 聚合与继承
- 插件管理
- assembly
- 资源管理插件
- 依赖范围
- 分环境打包
- dependencyManagement
- 版本分类
- 找不到主类
- 无法加载主类
- 私服
- svn
- gradle
- 手动引入第三方jar包
- 打包exe文件
- Windows
- java
- 设计模式
- 七大原则
- 1.开闭原则
- 2. 里式替换原则
- 3. 依赖倒置原则
- 4. 单一职责原则
- 单例模式
- 工厂模式
- 简单工厂
- 工厂方法模式
- 抽象工厂模式
- 观察者模式
- 适配器模式
- 建造者模式
- 代理模式
- 适配器模式
- 命令模式
- json
- jackson
- poi
- excel
- easy-poi
- 规则
- 模板
- 合并单元格
- word
- 读取
- java基础
- 类路径与jar
- 访问控制权限
- 类加载
- 注解
- 异常处理
- String不可变
- 跨域
- transient关键字
- 二进制编码
- 泛型1
- 与或非
- final详解
- Java -jar
- 正则
- 读取jar
- map
- map计算
- hashcode计算原理
- 枚举
- 序列化
- URLClassLoader
- 环境变量和系统变量
- java高级
- java8
- 1.Lambda表达式和函数式接口
- 2.接口的默认方法和静态方法
- 3.方法引用
- 4.重复注解
- 5.类型推断
- 6.拓宽注解的应用场景
- java7-自动关闭资源机制
- 泛型
- stream
- 时区的正确理解
- StringJoiner字符串拼接
- 注解
- @RequestParam和@RequestBody的区别
- 多线程
- 概念
- 线程实现方法
- 守护线程
- 线程阻塞
- 笔试题
- 类加载
- FutureTask和Future
- 线程池
- 同步与异步
- 高效简洁的代码
- IO
- ThreadLocal
- IO
- NIO
- 图片操作
- KeyTool生成证书
- 压缩图片
- restful
- 分布式session
- app保持session
- ClassLoader.getResources 能搜索到的资源路径
- java开发规范
- jvm
- 高并发
- netty
- 多线程与多路复用
- 异步与事件驱动
- 五种IO模型
- copy on write
- code style
- 布隆过滤器
- 笔试
- 数据库
- mybatis
- mybatis与springboot整合配置
- pagehelper
- 分页数据重复问题
- Java与数据库之间映射
- 拦截器
- 拦截器应用
- jvm
- 堆内存测试
- 线程栈
- 直接内存
- 内存结构
- 内存模型
- 垃圾回收
- 调优
- 符号引用
- 运行参数
- 方法区
- 分带回收理论
- 快捷开发
- idea插件
- 注释模板
- git
- pull冲突
- push冲突
- Excel处理
- 图片处理
- 合并单元格
- easypoi
- 模板处理
- 响应式编程
- reactor
- reactor基础
- jingyan
- 规范
- 数据库