maven依赖与传递性依赖

目录

• 依赖范围
• 传递性依赖
• 依赖调节
  • 可选依赖

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

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

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

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

</project>

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

依赖范围

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

• compile 默认，对于编译，测试，运行三个状态都有效
• test 顾名思义，只针对执行test代码
• provided 对于编译和测试时有效，但运行时无效，典型的时servlet-api，运行时这个由容器来提供
• runtime 对测试和运行时有效，但编译时无效
• system 与provided的范围一样，但system必须显示的指定依赖文件，通过<systemPath>来进行指定，是与本机绑定的，所以基本很少用到
• 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中重新进行依赖