• 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中重新进行依赖

  • 相关阅读:
    浏览器 cookie
    c# 委托
    并不对劲的loj3106:p5339:[TJOI2019]唱、跳、rap 和篮球
    并不对劲的loj3095:p5329:[SNOI2019]字符串
    并不对劲的CF1365D&E&F: Solve The Maximum Subsequence Again
    并不对劲的loj3123:p5404[CTS2019]重复
    并不对劲的loj3046:p5327:[ZJOI2019]语言
    并不对劲的loj3115:p5362:[SDOI2019]连续子序列
    并不对劲的loj3113:p5360:[SDOI2019]热闹的聚会与尴尬的聚会
    并不对劲的bzoj2521:p5039:[SHOI2010]最小生成树
  • 原文地址:https://www.cnblogs.com/westlin/p/10988207.html
Copyright © 2020-2023  润新知