Maven.2

5.依赖管理(了解)

5.1依赖传递

直接依赖：在当前项目中，通过依赖配置建立的依赖关系

间接依赖：被依赖的资源，如果还依赖其他资源，那么当前项目间接依赖其他资源

5.2依赖冲突

依赖冲突是指项目依赖的某一个jar包，有多个不同的版本，因而造成类包版本冲突。

解决方法：

1、第一生命者优先：调顺序（谁先定义的就用谁的传递依赖：即调换spring-aop和spring-context位置 ）
2、路径近者优先：直接引入 (直接依赖级别高于传递依赖：即直接引入spring-beans )
3、排除依赖

如图所示：

很好理解，当spring-core依赖出现冲突时，在不影响项目运行的情况下，可以将该冲突排除掉，即避让冲突
4、版本锁定

使用dependencyManagement 进行版本锁定

如图所示：

就是咬死了，你必须按我要的版本来，别的哪个版本都不好使！

效果如下：

6.依赖范围

6.3.1.什么是依赖范围？

依赖的jar包在默认情况下可以在任何范围内使用，可以通过scope标签来控制其作用范围。作用范围如下图：

很棒的一张图，但是有些看不懂。。。。

那这样呢？

还是有点懵？没关系，单个拆解

首先 scope，我们可以将其认为是依赖的生效范围

compile：翻译过来就是默认，其生效范围即默认在全局生效，如图所示：

可以在main包下的java运行生效，也可以在test包下的测试java中生效，也不影响打包中的jar

（ps：其实可以不写）

test：测试，再熟悉不过了，其生效范围就像它的名字一样，仅在测试中生效

一个test范围，在test类中：

毫无违和感，没有任何异常。

再看看 main：

结果显而易见

那么，打包呢？

看起来更加惨烈

我们甚至无法找到本应出现的war压缩包，以及我们的jar包。

因此，test依赖范围仅在test测试类中生效。

provided，其生效范围则是仅限main与test，并不负责打包。

runtime，单看run，便知道是跟运动有关的范围。

那么在主带码，测试代码，打包中，主带码基本是静态的，而test测试代码则是经常运行进行测试，测试运行完，便是打包，将jar包存放至本地仓库。

所以，测试类及打包是属于运行，就是runtime的生效范围。