maven完整学习笔记（2）--- 依赖范围和依赖传递

依赖基本配置

<dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.12</version>
        <scope>test</scope>
    </dependency>
</dependencies>

groupId、artifactId、version：基本坐标

type：依赖类型，默认是jar，和定义时的packaging一致

exclusions：排除某些依赖

scope：依赖范围，默认是compile

依赖范围

依赖中的scope标签，取值为：compile、test、provided、runtime、system、import；每种取值对不同的阶段的classpath生效

compile：默认值，对编译、运行、测试classpath有效

test：对测试classpath有效

provided：对编译、测试classpath有效，常见的例子是servlet-api

runtime：对运行、测试classpath有效

system：依赖范围和provided一致，不过需要指定路径依赖非maven方式，不常用

import：后面和dependencyManagement一起说明

依赖传递

maven引入的依赖传递机制有如下好处：项目开发只需要关注直接依赖即可，不需要关注这些依赖会引入哪些间接依赖；但也会引入一些问题，如：

A->B->D(2)，A->C->D(1)，那么A到底依赖的是D的哪个版本呢？

maven对于相同的依赖会有如下的原则：

1、路径最短原则

      A->B->C->G(2),  A->D->G(1)， 那么A间接依赖的G版本为1

2、路径长度相同时，以该依赖在pom中定义顺序为准，间接依赖先定义的

      A->B->D(1)，A->C->D(2)；在A的pom文件中，B的依赖在C的依赖之前，此时A依赖D的版本号为1

3、第2个有特例，如果一个pom中对某个依赖声明了两次，那么最后的依赖会覆盖前面的依赖；当然，很少人这么做

版本锁定原则

通过dependencyManagement实现，dependencyManagement只是在父pom中声明了依赖及版本号，并不会真正引入依赖；而继承了父pom的pom文件只需注明groupId、artifactId即可，无需指定版本号；

依赖范围的传递，后面讨论

scope为import

前面提到dependencyManagement用来声明依赖及版本号，而在dependencies中引入依赖；maven和java一样，是单继承的，即一个pom中只能有一个parent标签；

如果项目很庞大，那就会导致父pom中的依赖非常多，并且只能通过注释来分类，有没有其他解决方案呢？依赖范围import就是为了解决这个问题的；

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>2.2.6.RELEASE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

可以通过import引入spring-boot的依赖，注意使用import的前提是引入依赖的类型必须是pom并且要使用dependencyManagement标签

spring-boot-dependencies依赖如下：