maven依赖与传递性依赖

maven依赖与传递性依赖
目录

依赖范围
传递性依赖
依赖调节
本文主要是针对《maven实战》书中关键知识点的学习记录，未免有纰漏或描述不到之处，建议购买阅读原书

首先贴出一个pom常见的一些元素释义

4.0.0

<groupId>com.example</groupId>
<artifactId>my-demo</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>my-demo</name>
<packaging>pom</packaging>
<description>Demo project for Spring Boot</description>

<properties>
    <java.version>1.8</java.version>
</properties>


<dependencies>
    <dependency>
        <groupId></groupId>
        <artifactId></artifactId>
        <version>版本</version>
        <type>依赖的类型，对应于项目的packing，默认是jar</type>
        <scope>依赖范围</scope>
        <systemPath>配合 scope=system时使用</systemPath>
        <optional>标记是否为可选依赖</optional>
        <exclusions>
            用来排除传递性依赖
            <exclusion>

            </exclusion>
        </exclusions>

    </dependency>
</dependencies>

前面的坐标声明到依赖类型，都应该比较好理解，这里我们从依赖范围开始介绍起

依赖范围
maven中的依赖范围一共有以下几种

compile 默认，对于编译，测试，运行三个状态都有效
test 顾名思义，只针对执行test代码
provided 对于编译和测试时有效，但运行时无效，典型的时servlet-api，运行时这个由容器来提供
runtime 对测试和运行时有效，但编译时无效
system 与provided的范围一样，但system必须显示的指定依赖文件，通过来进行指定，是与本机绑定的，所以基本很少用到
import 不会对3总产生实际的影响，只能在dependencyManagement中使用
以表格来表示的，如下

scope 编译 测试 运行
compile Y Y Y
test Y
provided Y Y
runtime Y Y
system Y Y
传递性依赖
我们的工程，所使用的大多数情况下，不会只有一成依赖关系，例如 a依赖b，我们用a->b表示，那么，a->b，b->c，则a对于b是第一依赖，b对于c是第二依赖，而a对于c是传递性依赖

传递性依赖的scope传递规则，与第一依赖和第二依赖有关，下表第一列表示第一依赖，第一行表示第二依赖

compile test provided runtime
compile compile runtime
test test test
provided provided provided provided
runtime runtie runtime
从上表我们可以轻松得到几点信息

• 第二依赖为complie不改变第一依赖
• 第二依赖test不传递依赖
• 第二依赖provided只传递provided
• 第二依赖runtime对compile第一依赖的传递依赖是runtime
  依赖调节
  常遇到的问题是，有不同版本的包，他们都存在传递性依赖，如下
  a->b->c->x(1.0)
  a->b->x(2.0)
  那么此时，根据maven依赖调节第一原则最短路径的规则，使用的x包的版本是2.0，如果当2个不同版本的包的依赖相同怎么办？这个时候就启动了第二原则，也就是按pom中声明的顺序，谁先被声明，谁优先的策略去选择包。

可选依赖
假设有 a->b，b->x和 b->y的 optional值都是true，那么a对于x和y的依赖不会被传递，如果a想要使用x或y的包，那么需要在a中重新进行依赖