依赖:
1.当 A jar 包用到了 B jar 包中的某些类时,A 就对 B 产生了依赖,这是概念上的描述。那么如何在项目
中以依赖的方式引入一个我们需要的 jar 包呢?使用 dependency 标签指定被依赖 jar 包的坐标就可以了。
2.Maven解析依赖信息时,会到本地仓库中查找被依赖的jar包。(如果未找到第三方jar包,将会自动联网下载。对于我们自己开发的Maven工程,使用Install命令安装后就可以进入仓库)
3.依赖的范围:
4.依赖的传递性:A依赖B,B依赖C,A能否使用C呢?那要看B依赖C的范围是否是compile,如果是则可用,否则不可用。
a.可以传递的依赖不必在每个工程中都重复声明,在“最下面”的工程中依赖一次即可。
b.非compile范围的依赖不能传递,所以在各个工程模块中,如果有需要就得重复声明。如servlrt-api。
5.依赖的排除:如果我们在当前工程中引入了一个依赖是A,而A有依赖了B,那么Maven会自动将A依赖的B一如当前工程,但是个别情况下,B有可能是个不稳定版本,或对当前的工程有不良的影响。这时我们可以在引入A的时候将B进行排除。
比如:排除spring中log4j的依赖:
配置方式:
注:排除版本号的查询:a.点击“Dependency Hierarchy”
b.选中所要查询的jar包,点击“Open DOM”,出现了所有的坐标信息。
(在哪个工程中排除依赖,哪个工程中就没有了。相互依赖的工程,排除上面的,下面的有,排除下面的,上面的没有)
6.依赖的原则:
(1)作用:解决模块之间的jar包冲突问题
(2)a.路径最短者优先原则
b.路径相同时,先声明者优先。(先声明指的是dependency标签的声明顺序)
7.统一管理所依赖的jar包的版本:
对同一个框架的一组jar包,最好使用相同的版本,为了方便升级框架,可以将jar包的版本信息统一提取出来。
(1)统一声明版本号:
其中atguigu.spring.version部分是自定义标签。
(2)引用前面声明的版本号:
(3)其他用法:
注:其实properties标签配合自定义标签声明,并不是只能声明版本号。凡是需要统一声明后再引用场合均可以使用。
8.继承:(由于非compile范围的依赖信息是不能在“依赖链”中传递的,所以有需要的工程只能单独配置,这样容易造成版本的混 乱)
(1)如:Hello依赖的Junit:4.0
HelloFriend依赖的Junit:4.0
MakeFriend依赖的Junit:4.9
由于Junit的依赖范围是test不能传递,所以必然会分散在各个模块工程中,这样每个工程中,Junit的版本号均需要 设定,这样就很容易造成版本不一致。
(2)解决思路:将Junit依赖统一提取到“父工程”中,在子工程中声明Junit依赖时不指定版本,以父工程中统一设定的为准,同时也便于修改。
(3)操作步骤:
a.创建一个Maven工程为父工程,注意打包方式为pom。
b.在子工程中声明对父工程的引用。
注:此时如果子工程的 groupId 和 version 如果和父工程重复则可以删除。
c.将子工程的坐标中与父工程坐标中重复的内容删除。
d.在父工程中统一Junit的依赖。将 Parent 项目中的 dependencies 标签,用 dependencyManagement 标签括起来。
e.在子工程中删除Junit依赖的版本号部分。
注意:配置继承后,执行安装命令时,要先安装父工程,否则,子工程就无法安装了。