maven高级——依赖的传递性

文章目录

  • maven高级用法
    • 1、依赖的传递性
    • 2、依赖的排除
    • 3、依赖的原则
    • 4、统一管理依赖的管理
    • 5、继承
    • 6、聚合

maven高级用法

1、依赖的传递性

简单说吧,就是你现在有三个Moodle(暂时我们取名叫One、Two、Three),每个Moodle都是一个maven工程。而每个maven工程必定有他们自己专属的id,也就是我们平时说的agv。

依赖的传递性就是,现在Three导入了Two的gav,而Two导入了One的gav,那么,此时One导入的所有的依赖,也会跟着被Two和Three导入。此时呢,Two对于Three来说是直接依赖,而One对于Three就称之为传递依赖。

优点:可以传递的依赖不必在每个Moodle中都重复声明。只需要在“根”工程中导入一次即可。
注意:非compile的依赖不进行传递。(例如test、provided)如果一定要添加的话,就得在各个Maven工程下逐个添加。

2、依赖的排除

这个在SpringBoot中应该还算挺常见的。
用法也很简单,比如,你现在不想要一个大的依赖下的某个小的依赖。你只需要在他的gav的同级添加一个excludes标签,再把想要排除的每个jar包的ga属性写在单独的exclude标签下即可。
举个例子:(这是一个很烂的例子哈,只是用来说明怎么排除依赖,实际开发应该不会让spring-core排除spring-jcl,至少我是没遇到过)

<dependency>
    <groupId>org.springframeworkgroupId>
    <artifactId>spring-coreartifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframeworkgroupId>
            <artifactId>spring-jclartifactId>
        exclusion>
    exclusions>
dependency>

3、依赖的原则

原则一、就近原则

假如现在有三个Maven工程:One、Two、Three,其中Three依赖Two、Two依赖One。而这个时候,One依赖log4j 1.2.17, Two由于特殊需要依赖了log4j 1.2.14, 此时Three将面临有两个log4j的jar包的选择。 maven在这种情况下的策略是就近原则。也就是他会优先使用他直接依赖的Two工程下的log4j 1.2.14包。
maven高级——依赖的传递性_第1张图片
如果,我们的Three就是要用One的17版本怎么办呢?很简单,自己声明就好了。自己写自己的依赖是log4j 1.2.17,问题解决。

原则二、先声明者优先原则
假如现在有三个Maven工程:One、Two、Three,其中Three分别依赖One和Two。而这个时候,One依赖log4j 1.2.17, Two依赖了log4j 1.2.14, 此时Three将面临有两个log4j的jar包的选择,这个时候One和Two都是Three的直接依赖。 maven在这种情况下的策略是先声明者优先原则。也就是他会优先使用他比较前面定义的那个dependency。

如果是下面这种,先声明了Two依赖,再声明One依赖的,那么就使用log4j 1.2.14.
maven高级——依赖的传递性_第2张图片

4、统一管理依赖的管理

假如我们现在有个项目,他以前用的是Spring4版本的依赖,现在我们要把他全部换成Spring5的依赖。这个时候,如果我们手动一个个去改,可想而知有多麻烦。而且,还有可能会改少几个或者改错几个。这种方式明显就很不可靠。
maven高级——依赖的传递性_第3张图片
这个时候我们就要统一配置我们的依赖了。这个可以参考一下Springboot的starter的写法。(这里以SpringBoot的druid-spring-boot-starter为例吧)

首先,我们配置我们的properties,进行统一声明。properties下的标签名是自己取的。引用的时候只需要用 ${properties中定义的标签名来取值即可}
maven高级——依赖的传递性_第4张图片
引用如下:
maven高级——依赖的传递性_第5张图片
maven高级——依赖的传递性_第6张图片
如此,我们针对上面的Spring4要统一改成Spring5就简单多了。直接修改Properties标签下我们自定义标签的一个版本号即可。

注意:Properties标签不仅有上面这个用处,凡是统一声明后再引用的场合都可以像上面这么用。(在properties中定义自己的标签,然后用${自定义标签}来取值)

5、继承

由于test范围的依赖不能传递,所以必然会分散在各个模块工程中,很容易造成版本不一致。比如我们的junit,有些模块可能用junit4,有些模块用的是junit5,这个时候,就很有可能会出一些大问题。
所以我们就有了统一管理各个模块工程依赖的需求。
解决的思路是:将依赖版本提取到“父”工程中,在子工程中声明依赖时,我们直接不声明版本号。

这里我们以spring-boot-starter-parent为例。直接扣他的内容来看,站在巨人的肩膀上学习。
步骤1、写一个Maven工程(父工程),打包方式定义为pom。
maven高级——依赖的传递性_第7张图片
步骤2、在子工程中声明对父工程的引用。
maven高级——依赖的传递性_第8张图片
步骤3、在父工程中声明统一的jar包的依赖:(使用dependencyManagement标签)
maven高级——依赖的传递性_第9张图片
上面的version都是用${。。。}形容的,这个前面讲过了,都是在properties标签中写好的:
maven高级——依赖的传递性_第10张图片
步骤4、在子工程中导入依赖的时候,如果父工程已经声明了版本号,那么我们可以不用写。(可以看到,下面这几个都没有定义他们的version)
maven高级——依赖的传递性_第11张图片

6、聚合

作用:一键安装各个模块工程。
配置方式:在一个总的聚合工程中配置各个参与聚合的模块
情景:假如现在我们有一个Parent工程,是One、Two、Three的父工程。而这四个工程呢,又都是Maven_workstation项目下的四个Moodle。此时,我们如果在外面要通过他的pom.xml下载这几个Moodle,不适用聚合的情况下,就得先下载Parent工程,再分别下载One、Two、Three工程,这显然很麻烦。所以,我们就可以用我们的聚合:

    
    <modules>
        
        <module>../Onemodule>
        <module>../Twomodule>
        <module>../Threemodule>
    modules>

如此,我们只需要下载我们的Parent工程,就会自动把One、Two、Three工程也一起下载下来了。

你可能感兴趣的:(maven,maven,spring,java)