maven依赖传递

maven依赖机制

1、优先原则

（1）A、B、C的依赖关系被定义为A -> B -> C -> D 2.0和A -> E - >d 1.0，那么构建A时将使用D 1.0，因为从A经过E到D的路径较短。你可以在a中显式地向D 2.0添加依赖，强制使用D 2.0，如下图所示：

（2）先声明者优先

2、排除依赖

如果项目X依赖于项目Y，项目Y依赖于项目Z，项目X的所有者可以使用“exclusion”元素显式地排除项目Z作为依赖项

<dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>easyexcel</artifactId>
            <version>3.0.5</version>
            <exclusions>
                <exclusion>
                    <groupId>org.apache.xmlbeans</groupId>
                    <artifactId>xmlbeans</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

3、optional

如果项目Y依赖于项目Z，项目Y的所有者可以使用“optional”元素将项目Z标记为可选依赖。当项目X依赖于项目Y时，X将只依赖于Y而不依赖于Y的可选依赖项Z。项目X的所有者可以根据自己的选择显式地添加对Z的依赖项

4、显示的指定依赖

尽管传递依赖可以隐式地包含所需的依赖，但最好还是显式地指定源代码直接使用的依赖。尤其是当项目的依赖关系发生更改时。
例如，假设你的项目A依赖于另一个项目B，而项目B依赖于项目C。如果你直接在项目C中使用组件，而在项目A中没有指定项目C，那么当项目B突然更新/删除它对项目C的依赖时，可能会导致构建失败。
直接指定依赖关系的另一个原因是，你可以通过阅读项目中的POM文件或执行mvn dependency:tree来了解更多信息，阅读起来更加直观

5、Dependency Scope 依赖范围

compile

这是默认作用域，如果不指定则使用。编译依赖项在项目的所有类路径中都可用。此外，这些依赖关系会传播到依赖的项目。

provided

跟 compile 很像，但是如果希望在JDK或容器在运行时提供依赖项时采用。例如，在为Java企业版构建web应用程序时，您可以将Servlet API和相关Java EE API的依赖关系设置为作用域 provided ，因为web容器提供了这些类。具有此作用域的依赖会添加到用于编译和测试的类路径中，但不会添加到运行时类路径中。它是不可传递的。
在标准的 Maven 项目中，当依赖被设置为 provided 作用域时，Maven 在打包时（例如使用 mvn package）确实不会将这些依赖包含在生成的 JAR 或 WAR 文件中。这是因为这些依赖被假定为在运行时将由运行环境（如应用服务器或容器）提供。
然而，Spring Boot 的 Maven 插件在处理 provided 依赖时有所不同。Spring Boot 试图创建一个“可执行的 JAR”或“可部署的 WAR”，这意味着它希望尽可能地自包含，即使这些依赖项在标准 Maven 打包过程中会被排除。
在 Spring Boot 项目中，当你使用 spring-boot-maven-plugin 进行打包时，即使依赖被标记为 provided，它也可能被包含在最终的 JAR 或 WAR 文件中。Spring Boot 这样做的目的是为了简化部署和确保应用程序的独立性，特别是当部署到没有预安装依赖项的环境时。
对于 WAR 文件，Spring Boot 有一个特性，它会创建一个名为 WEB-INF/lib-provided 的目录，并将所有 provided 依赖放入这个目录。然而，这些依赖并不会被 Servlet 容器自动添加到类路径中。它们只是作为备份存在，以防容器没有提供这些依赖。实际上，在大多数情况下，lib-provided 目录中的 JAR 文件不会被使用，除非你明确配置容器去加载它们。
对于 JAR 文件，Spring Boot 通常会将所有依赖（包括 provided）打包到 BOOT-INF/lib 目录下。但是，由于 provided 依赖在运行时预期是由环境提供的，Spring Boot 在运行时不会将它们添加到类路径中。
如果你不希望 Spring Boot 将 provided 依赖包含在最终的 JAR 或 WAR 文件中，你可以尝试以下几种方法：
手动排除：在 spring-boot-maven-plugin 的配置中，使用 元素来手动排除特定的 provided 依赖。
使用 Maven 依赖管理：确保你的 pom.xml 文件中正确设置了依赖的范围为 provided。
考虑是否真正需要 provided：如果你确定依赖在运行时总是可用的（例如，因为你正在部署到一个总是提供这些依赖的特定环境中），那么使用 provided 作用域是合理的。否则，你可能需要重新考虑是否应该将这些依赖包含在最终包中。

runtime

此范围表明编译不需要依赖项，但执行需要依赖项。Maven在运行时和测试类路径中包含了这个作用域的依赖，但在编译类路径中没有。加了runtime的jar包在代码编写的时候是无法引用的

test

仅在测试编译和执行阶段可用

system

这个作用域类似于 provided ，必须在项目中引入此jar包，并且标注jar的位置

        <dependency>
          <groupId>dingding</groupId>
          <artifactId>dingding</artifactId>
          <version>2.8</version>
          <scope>system</scope>
          <systemPath>${project.basedir}/lib/taobao-sdk-java.jar</systemPath>
        </dependency>

import

此作用域仅支持 节中的类型 pom 。作用域为 import 的依赖实际上并不参与限制依赖的传递性

<groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-dependencies</artifactId>
  <version>2.4.0</version>
  <packaging>pom</packaging>
  <name>spring-boot-dependencies</name>
  <description>Spring Boot Dependencies</description>
  <dependencyManagement>
    <dependencies>
    <dependency>
        <groupId>io.dropwizard.metrics</groupId>
        <artifactId>metrics-bom</artifactId>
        <version>${dropwizard-metrics.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
</dependencyManagement>
    

<artifactId>metrics-bom</artifactId>
    <name>Metrics BOM</name>
    <packaging>pom</packaging>
    <description>Bill of Materials for Metrics</description>
     <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>io.dropwizard.metrics</groupId>
                <artifactId>metrics-annotation</artifactId>
                <version>${project.version}</version>
            </dependency>
     </dependencies>
</dependencyManagement>

compile、runtime和provided的区别，需要在执行mvn package命令，且打包格式是war之类（而不是默认的jar）的时候才能看出来。通过compile和provided引入的jar包，里面的类，你在项目中可以直接import进来用，编译没问题，但是runtime引入的jar包中的类，项目代码里不能直接用，用了无法通过编译，只能通过反射之类的方式来用。通过compile和runtime引入的jar包，会出现在你的项目war包里，而provided引入的jar包则不会。

传递性依赖的依赖范围受第一直接依赖和第二直接依赖的范围影响，如下表所示。

6、dependencyManagement依赖传递的一个问题

###父依赖中dependencyManagement管理的依赖优先级高于子项目中引入依赖的依赖。

本项目中的依赖

<parent>
        <groupId>com.test</groupId>
        <artifactId>common-parent</artifactId>
        <version>1.1.1</version>
    </parent>
    <dependencies>
        <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>easyexcel</artifactId>
            <version>3.0.5</version>
        </dependency>
    </dependencies>

父依赖

<groupId>com.test</groupId>
	<artifactId>common-parent</artifactId>
	<version>1.1.1</version>
	<packaging>pom</packaging>
	<name>common-parent</name>
    <dependencyManagement>
        <dependencies>
            <dependency>
				<groupId>org.apache.poi</groupId>
				<artifactId>poi-ooxml</artifactId>
				<version>4.0.0</version>
			</dependency>
          </dependencies>
</dependencyManagement>

easyexcel中的依赖

本项目中excel实际引入的依赖