maven高级——依赖的传递性

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包。

如果，我们的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.

4、统一管理依赖的管理

假如我们现在有个项目，他以前用的是Spring4版本的依赖，现在我们要把他全部换成Spring5的依赖。这个时候，如果我们手动一个个去改，可想而知有多麻烦。而且，还有可能会改少几个或者改错几个。这种方式明显就很不可靠。

这个时候我们就要统一配置我们的依赖了。这个可以参考一下Springboot的starter的写法。（这里以SpringBoot的druid-spring-boot-starter为例吧）

首先，我们配置我们的properties，进行统一声明。properties下的标签名是自己取的。引用的时候只需要用 ${properties中定义的标签名来取值即可}

引用如下：


如此，我们针对上面的Spring4要统一改成Spring5就简单多了。直接修改Properties标签下我们自定义标签的一个版本号即可。

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

5、继承

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

这里我们以spring-boot-starter-parent为例。直接扣他的内容来看，站在巨人的肩膀上学习。
步骤1、写一个Maven工程（父工程），打包方式定义为pom。

步骤2、在子工程中声明对父工程的引用。

步骤3、在父工程中声明统一的jar包的依赖：（使用dependencyManagement标签）

上面的version都是用${。。。}形容的，这个前面讲过了，都是在properties标签中写好的：

步骤4、在子工程中导入依赖的时候，如果父工程已经声明了版本号，那么我们可以不用写。（可以看到，下面这几个都没有定义他们的version）

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工程也一起下载下来了。