Maven 依赖调解源码解析（三）：传递依赖，路径最近者优先

2021 年 11 月 20 日
本文字数：4862 字
阅读完需：约 16 分钟

本文是系列文章《Maven 源码解析：依赖调解是如何实现的？》第三篇，主要介绍依赖调解的第一条原则：传递依赖，路径最近者优先。本篇内容较多，也是开始源码分析的第一篇，请务必仔细阅读，否则后面的文章可能就看不懂了。系列文章总目录参见：https://xie.infoq.cn/article/de675251f0675d7cffa198ec0。

场景

A 有这样的依赖关系：A－＞B－＞C－＞X（1.0）、A－＞D－＞X（2.0），X 是 A 的传递性依赖，但是两条依赖路径上有两个版本的 X，那么哪个 X 会被 Maven 解析使用呢？两个版本都被解析显然是不对的，因为那会造成依赖重复，因此必须选择一个。根据路径最近者优先原则，该例中 X（1.0）的路径长度为 3，而 X（2.0）的路径长度为 2，因此 X（2.0）会被解析使用。

A 的 pom.xml 内容如下：

<?xml version="1.0" encoding="UTF-8"?><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">    <parent>        <artifactId>mavenDependencyDemo</artifactId>        <groupId>org.example</groupId>        <version>1.0</version>    </parent>    <modelVersion>4.0.0</modelVersion>
    <artifactId>A</artifactId>    <version>1.0</version>
    <dependencies>        <dependency>            <groupId>org.example</groupId>            <artifactId>B</artifactId>            <version>1.0</version>        </dependency>
        <dependency>            <groupId>org.example</groupId>            <artifactId>D</artifactId>            <version>1.0</version>        </dependency>

    </dependencies>
</project>

复制代码

B 的 pom.xml 内容如下：

<?xml version="1.0" encoding="UTF-8"?><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">    <parent>        <artifactId>mavenDependencyDemo</artifactId>        <groupId>org.example</groupId>        <version>1.0</version>    </parent>    <modelVersion>4.0.0</modelVersion>
    <artifactId>B</artifactId>    <version>1.0</version>
    <dependencies>        <dependency>            <groupId>org.example</groupId>            <artifactId>C</artifactId>            <version>1.0</version>        </dependency>    </dependencies>
</project>

复制代码

C 的 pom.xml 内容如下：

<?xml version="1.0" encoding="UTF-8"?><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">    <parent>        <artifactId>mavenDependencyDemo</artifactId>        <groupId>org.example</groupId>        <version>1.0</version>    </parent>    <modelVersion>4.0.0</modelVersion>
    <artifactId>C</artifactId>    <version>1.0</version>
    <dependencies>        <dependency>            <groupId>org.example</groupId>            <artifactId>X</artifactId>            <version>1.0</version>        </dependency>    </dependencies>
</project>

复制代码

D 的 pom.xml 内容如下：

<?xml version="1.0" encoding="UTF-8"?><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">    <parent>        <artifactId>mavenDependencyDemo</artifactId>        <groupId>org.example</groupId>        <version>1.0</version>    </parent>    <modelVersion>4.0.0</modelVersion>
    <artifactId>D</artifactId>    <version>1.0</version>
    <dependencies>        <dependency>            <groupId>org.example</groupId>            <artifactId>X</artifactId>            <version>2.0</version>        </dependency>    </dependencies>
</project>

复制代码

源码

刚拿到源码不知道从哪里打断点，我们可以先切换到模块 A 中，执行一下这个命令：

 mvn dependency:tree -Dverbose

复制代码

其中的 verbose 是为了输出详细信息，方便我们找到源码中的参照点。

可以发现输出为：

[INFO] Scanning for projects...[INFO] [INFO] ---------------------------< org.example:A >----------------------------[INFO] Building A 1.0[INFO] --------------------------------[ jar ]---------------------------------[INFO] [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ A ---[INFO] org.example:A:jar:1.0[INFO] +- org.example:B:jar:1.0:compile[INFO] |  \- org.example:C:jar:1.0:compile[INFO] |     \- (org.example:X:jar:1.0:compile - omitted for conflict with 2.0)[INFO] \- org.example:D:jar:1.0:compile[INFO]    \- org.example:X:jar:2.0:compile[INFO] ------------------------------------------------------------------------[INFO] BUILD SUCCESS[INFO] ------------------------------------------------------------------------[INFO] Total time:  1.002 s[INFO] Finished at: 2021-11-20T12:17:29+08:00[INFO] ------------------------------------------------------------------------

复制代码

可以看到，A 依赖了 X（2.0），而 X（1.0）被忽略了。这句关键信息是

(org.example:X:jar:1.0:compile - omitted for conflict with 2.0)

复制代码

那我们分别到 apache-maven-3.6.3、maven-dependency-plugin 和 maven-dependency-tree 这三个项目中找一下，看看是哪里输出的这句话。

我们最终在 maven-dependency-tree 这个插件项目中发现了这段输出的源头：

此时我们可以用前面讲述的调试方法（注意是调试插件 maven-dependency-tree），在这里打断点，从而找出调用链：

很明显，这个 TreeMojo 就在 maven-dependency-plugin 项目中了：

结合前面在 maven-dependency-tree 中的调用链，可知是在 TreeMojo#serializeVerboseDependencyTree 这个方法中，以访问者方式序列化依赖关系，这里面用到的 visitor 是 BuildingDependencyNodeVisitor ,可以回到 maven-dependency-tree 项目查看调用链加以印证：

这一步明确之后，我们继续分析 maven-dependency-tree 刚才打断点的地方，看看为什么能进到这里，也即有哪些上下文。

我们发现，重点是 state 这个字段，因此看看哪里给它赋了值。

根据上图可以看出，只有一处赋值了 OMITTED_FOR_CONFLICT，点进去看看：

顺便可以看到：

1、如果重复声明的依赖版本号相同，那么 state 是 OMMITTED_FOR_DUPLICATE，意味着重复。

2、如果重复声明的依赖版本号不同，那么 state 是 OMMITTED _FOR_CONFLICT，意味着冲突，最终必然只会选其中的一个。

继续往上找调用链：

我们发现 omitForNearer 这个方法的定义在 apache-maven-3.6.3 这个核心项目中的 ResolutionListener 类中，而插件 maven-dependency-tree 中的 DependencyTreeResolutionListener 负责了具体的实现。

那么我们中断此次调试，并在 omittedNode.omitForConflict( kept ) 这里打个断点，重新调试，看看上下文都有什么：

可以看到，要被忽略的依赖和要被保留的依赖，是由上层传入的。也就是说，apache-maven-3.6.3 这个核心项目已经做出了「应该保留哪个依赖」的判断。

因此我们再次中断调试，回到 apache-maven-3.6.3 核心项目重新调试。

按照刚才的分析，我们找到 omitForNearer 被调用的地方，打上断点：

断点进来后，我们顺着调用链网上找，看看是在哪里决定的：

可以看到，是在 org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector#recurse 这个方法中决定的。看起来，似乎关键方法是 checkScopeUpdate( farthest, nearest, listeners )。我们需要点进去看看，它直接决定了哪个依赖被忽略，哪个依赖被保留。

我们再次重新调试。为方便，可以设置条件断点 "X".equals(((DefaultArtifact) nearest.artifact).artifactId)，只关心 X 依赖。

可以看出，这个方法只是根据 scope 优先级进行处理，总而言之就是保留优先级更高的依赖。然而这并不是我们的场景。

因此，我们应该顺着调用链继续往上找。

重新调试（或者先回退调用栈，再前进），会发现进入到了这里：

可以看到，nearest 来源于 node，farthest 来源于 previous。而且这个赋值关系受到 resolved 和 previous 的相等关系控制。那我们分别看看 previous、 resolved 以及 node 的来源。

往上翻，可以看到 previous 也即 X（1.0）和 node 也即 X（2.0）均是在上一步解析得到的：

而 resolved 是在这里解析得到的：

结合前面的分析，我们就可以知道：

如果 resolved 和 previous 相同，那么保留 previous，忽略 node；反之，保留 node，忽略 previous。

那我们需要看看这行代码内部究竟干了啥：

resolved = conflictResolver.resolveConflict( previous, node );

复制代码

调试进入：

可以看出我们进入了 NearestConflictResolver 这个冲突调解器，具体地，它会选择路径最近的依赖。从实现层面看，非常简单：它直接比较两个依赖的路径深度，发现 X（1.0）的深度为 3，X（2.0）的深度为 2，按照规则，需要保留路径深度更小的 X（2.0）。

那么问题来了，什么时候会调用 conflictResolver.resolveConflict( previous, node ) 呢？看下图：

处理完这一步之后，会把 X（2.0）也加入 previousNodes 中：

还有个小尾巴，上面我们提到： previous 也即 X（1.0）和 node 也即 X（2.0）均是在上一步解析得到，让我们看看：

其实很容易发现，依赖的解析过程就是一种深度遍历，这里的 recurse 方法会被不断递归。用我们的例子来理解，先遍历了 A－＞B－＞C－＞X（1.0），然后遍历了 A－＞D－＞X（2.0），我们刚刚调试的过程正处于 D－＞X（2.0）刚刚完成的时刻。

好了，当这些递归遍历结束后，返回到 org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector#collect 方法，准备生成结果：

可以看到，只有 isActive 的依赖才会被收集到结果中，也就是最终起作用的依赖版本。其实 active 的设置就是在之前的这个步骤实现的：

可以看到，如果一个依赖被忽略，它本身的所有依赖也会被忽略。

小结

至此，我们已经知道了路径最近者优先原则的运行原理：依赖的解析是一种深度遍历的过程，每当解析一个依赖时，均会放到 resolvedArtifacts 这个 Map 中，后续再看到同名的依赖时，进行冲突调解。对于路径最近者优先原则来说，具体的冲突调解器是 NearestConflictResolver。

扩展一下：上述分析过程中，我们看到了 ConflictResolver 这个接口，发现它是专门进行依赖调解的，不同的调解方式应该就是由具体的实现类来处理。对于路径最近者优先原则来说，就是由 NearestConflictResolver 处理。那其他的原则会由其他的依赖调解器处理吗？

就让我们看看都有哪些具体的依赖调解器：