Maven的依赖管理

Maven中的依赖scope

scope定义了依赖的项目在编译、测试、打包三个不同阶段是否生效，下面列举了三个阶段中依赖是否生效的具体表现，以加深理解：

首先是编译阶段，这个阶段将用户的java文件编译成class文件，如果依赖在这个阶段不生效，那么当用户的主代码中使用了该依赖中的类时，会造成编译失败。具体现象是mvn compile失败，或者更直观的，在ide中提示找不到类，编译错误。

然后是测试阶段，如果依赖在测试阶段不生效，那么如果用户在测试代码中使用了该依赖中的类，会引起测试代码编译失败。

最后是打包阶段，如果依赖在打包阶段不生效，简单来说，打包后的文件中不会存在该依赖的jar包。这样打包后的文件，在后续运行阶段需要另外提供该依赖的jar包，否则当jvm尝试将该依赖中的class文件加载到内存中时，会报错找不到类。在不同的打包场景下，依赖是否生效的具体表现也是不同的，需要具体场景具体分析：

• 打war包：依赖是否生效意味着，该依赖的jar包是否出现在WEB-INF/lib目录中
• maven-assembly-plugin打jar包（包含依赖的包）：依赖是否生效意味着，是否将该依赖的jar包打进去（默认配置下的表现，实际上assembly-plugin配置自由度很高）
• maven-jar-plugin打普通的jar包（只包含主代码）：依赖是否生效意味着，如果指定了addClasspath，那么MANIFEST.MF中是否包含该jar包的路径

依赖在上述三个阶段是否生效有多种排列组合，maven定义了多个scope来描述这些场景，官方文档说明中共有6种scope：compile provided runtime test system import，常用和需要关注的有5种 compile provided system runtime test，而import比较特殊，使用的场景和其他几种完全不同，这里暂时不讨论。

这些scope和依赖在三个阶段是否生效的关系如下：

可以看到，依赖配置任何scope对于测试阶段都是生效的，相当于scope对测试其实是透明的，只要声明了依赖，对测试来说就是生效的。

那么这几种scope一般用在什么场景下呢？

compile是默认的配置，适用的场景是：如果依赖在编译阶段需要引入（用户写的主代码引用了依赖中的类），而且期望打包到lib中，那么就要声明为compile。

runtime适用的场景：编译阶段不需要，比如对于jdbc的具体实现mysql-jdbc，由于代码中直接使用的是jdbc的接口，所以编译阶段不需要依赖mysql-jdbc，如果同时我们希望将mysql-jdbc打包到lib中，以供运行阶段使用，则需要将该依赖声明为runtime。

provided适用的场景：依赖在编译阶段需要，但是我们不希望将该依赖打包到lib中，因为执行的容器已经提供了该jar包，如果我们重复提供可能会引起jar包冲突，比如打包flink任务的jar包时，flink相关的依赖，引擎已经提供了，就不需要也不应该打包进去。

system可以认为和provided一致，只是必需要额外指定一个本地路径，这个一般不推荐使用。

test适用的场景很单一，如果一个依赖只是和测试代码相关的，主代码不使用，那就就声明为test，该依赖在编译和打包时都会忽略。

Maven中的依赖传递

首先要明确的是依赖传递解决的是什么问题，场景如下：

项目A依赖项目B，项目B依赖项目C，写作A->B，B->C

那么项目A对项目C的依赖关系是怎样的？这就是依赖传递要解决的问题。

依赖传递的复杂性主要体现在不同scope下的表现不同，如图所示：

https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

image-20210717183403288

上表中左侧的列是外层依赖（A->B）的scope，第一行是内层依赖（B->C）的scope，那么A->C的依赖结果为交叉点的结果。

结果说明：“-”表示不依赖，不依赖的结果是：A项目在编译、测试、打包时都不能访问C项目。

上表有几个典型的规律：

1.provided/test的依赖一定不会传递到外层

2.compile的依赖传递到外层时和外层的依赖scope相同

3.runtime的依赖传递到外层时和外层的依赖scope相同，除非外层是compile，会保持runtime

上述的规律还不足以明确地指导我们的使用，我们从具体的场景进行分析，分为两类问题：

• 问题一：如果我是A的开发，当我声明A->B的scope时，对A->C的依赖有什么影响？
• 问题二：如果我是B的开发，当我声明B->C的scope时，对A->C的依赖有什么影响？

问题一：

最常见的场景，我声明了A->B为compile，这已经是对B最强的依赖了，对于B内部的依赖C

• 如果是compile，会将compile传递出来，C在我的编译和打包阶段都会生效

• 如果是runtime，那我对C的依赖也是runtime，编译阶段我不能使用C了，毕竟B也不能用，我对B的内部的C权限也不能更高，这一点符合直觉；在打包时，C会打包到lib包中，这个需求是显然的，否则很可能B项目运行阶段会报错。

  那么我可以将C声明为provided吗？可以，只要我确信这个包在运行时会提供，这样带来的好处是可以避免jar包冲突，这样引入了一个技巧，为了避免C的jar包冲突，除了到每一个B依赖中排除掉依赖之外，也可以在A项目中，显示声明C为provided，这样更加简洁高效一些

• 如果是provided或者test，我应当清楚，我不会对C有依赖

第二个场景，我声明了A->B为provided，B不会打入我的jar包，而运行时会提供B的jar包，对于B内部的依赖C

• 如果是compile，此时我对C的依赖为provided，即我可以编译阶段使用C，但C也不会打入我的jar包。
• 如果是runtime，我对C的依赖变成了provided，在编译阶段看来，这似乎是一种强化，B不能直接使用C的类，我却可以了；在打包阶段看来，被弱化了，我不会将C打入自己的jar包，这一点与外层B的provided是一致的
• 如果是provided或者test，我应当清楚，我不会对C有依赖

第三个场景，我声明了A->B为runtime，B会打入我的jar包，对于B内部的依赖C，编译阶段我一定不能使用，毕竟B我都不能使用，这一点是符合直觉的；那么打包阶段呢，我会将compile和runtime的C打入jar包，忽略provided和test

第四个场景，我声明了A->B为test，同样B的provide和test不会被我访问到，但是B的compile和runtime依赖我可以在测试中自由使用，这里runtime似乎也升级了

问题二：

最常见的场景，我声明了B->C为compile，因为我对C的依赖是足够强的，我会期望外部对我的依赖scope也会透传到对C的依赖。

第二个场景，我声明了B->C为provided或test，这意味着外界对C完全不可见，不能编译，也不会打包自己的项目。

第三个场景，我声明了B->C为runtime，外部对我的依赖scope也会透传到对C的依赖，这个其实是不太安全的，这个时候我会发现我编译阶段不能依赖的C，外部反而可以了，这个时候我对投传下来的compile降级为runtime，其他的未做处理。