版本依赖冲突问题排查过程记录

本文介绍: 开发平台在集成 minio时，pom 引入了sdk。在调用上传文件API时，控制台报错：从错误来看，是okhttp的版本过低，minio要求版本4.11.0及以上.初看这错误一脸懵，okhttp是minio 内部依赖的jar包，难不成其他地方也在使用，造成了版本冲突？使用 maven helper 插件提供的jar包依赖分析，发现并没有出现 okhttp 冲突的情况。然后整个项目工程中搜索 okhttp 关键字，任何模块没有显性使用过。查看使用 mini o 组件模块的依赖，确认当前使用的okhttp的版本是3.14.8，明显低

问题

开发平台在集成 mini o时，pom 引入了sdk。

&lt;dependency&gt;
    <groupId>io.minio</groupId>
    <artifactId>minio</artifactId>
    <version>8.5.7</version>
</dependency>

在调用上传文件API时，控制台报错：

从错误来看，是okhttp的版本过低，m i nio要求版本4.11.0及以上.
初看这错误一脸懵，ok http是m i nio 内部依赖的jar包，难不成其他地方也在使用，造成了版本冲突？

排查

使用 maven helper 插件提供的ja r包依赖分析，发现并没有出现 ok http 冲突的情况，如下图：

然后整个项目工程中搜索 ok http 关键字，任何模块没有显性使用过。
查看使用 minio 组件模块的依赖，确认当前使用的ok http的版本是3.14.8，明显低于控制台中提示的版本4.11.0。

这就奇怪了，其他模块没有使用ok http，为什么会出现了与min io要求不一致的版本呢？

尝试

调整使用min io 组件的oss 模块的pom 文件，将min io的引用中排除ok http，然后再单独添加对ok http4.12.0版本的依赖。

<dependency>
  <groupId>io.minio</groupId>
  <artifactId>minio</artifactId>
  <version>8.5.7</version>
  <exclusions>
    <exclusion>
      <artifactId>okhttp</artifactId>
      <groupId>com.squareup.okhttp3</groupId>
    </exclusion>
  </exclusions>
</dependency>
<dependency>
  <groupId>com.squareup.okhttp3</groupId>
  <artifactId>okhttp</artifactId>
  <version>4.12.0</version>
</dependency>

使用maven clean install，查看依赖的okhttp，仍然是旧版本，上述调整并没有生效。
注：网上不少文章都是这么做的，实际并不能解决问题。

对比

与原来做技术验证的miniodemo 项目对比，查看依赖的okhttp包，其版本是正常的，如下图所示：

此对比确认 minio组件自身没有问题，基本确定问题根源在于开发平台的环境上。

定位

问题排查到这一步，基本能定位根源了，就是开发平台使用了spring–boot–dependencies来管理组件内部的依赖关系。

  <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-dependencies</artifactId>
      <version>${springboot.version}</version>
      <type>pom</type>
      <scope>import</scope>
  </dependency>

这么做是因为众多的组件，常常会因为版本不兼容引发冲突和异常，spring–boot–dependencies会将经过严格的兼容性测试的组件版本进行统一维护和管理。附带的另一个好处是，引用组件时只需要指定groupId和a rtifactId，version 属性可以省略。
在spring–boot–dependencies的pom 文件中搜索okhttp，果然发现里面定义的版本3.14.8，与上面的有冲突的版本一致。

解决

问题根源找到了，解决自然也容易。在项目的根pom中，引入okhttp，指定版本，这么做会覆盖 spring–boot–dependencies的版本设置，但同时也意味着需要你自行确保新版本的okhttp与其他组件不存在冲突。

  <!-- 依赖声明 -->
    <dependencyManagement>
        <dependencies>
            <!--spring boot dependencies-->
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-dependencies</artifactId>
                <version>${springboot.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
          	……
            <!--强制指定版本，优先级高于spring-boot-dependencies-->
            <dependency>
                <groupId>com.squareup.okhttp3</groupId>
                <artifactId>okhttp</artifactId>
                <version>4.12.0</version>
            </dependency>

        </dependencies>
    </dependencyManagement>

反思

实际该情况并不是第一次遇到，之前lombok组件也曾出现过类似的问题，其现象是编辑器报类似如下警告： java: You aren’t using a compiler supported b y lombok, so lombok wi ll not work and has been disabled. Your processor is: com.sun.proxy.$Proxy8 Lombok supports: OpenJDK javac, ECJ。
按照上述方式设置了lo mbok的新版本后，问题解决。

同时，需要注意这里有个反常识的地方，即全局的依赖管理，优先级要高于具体模块的pom 配置。

java中库特别多，版本也很多，组合使用是存在版本冲突问题。例如在使用Spr ing的时候，经常会使用到第三方库，一般大家都是根据经验挑选一个版本号或挑选最新的，随意性较大，其实这是有问题的，除非做过完整的测试，保证集成该版本的依赖不会出现问题，且后续集成其它第三方库的时候也不会出现问题，否则风险较大，且后续扩展会越来越困难，因为随着业务复杂度的增加，集成的第三方组件会越来会多，依赖之间的关联也会也来越复杂。

除了本文提到的用于 springboot 项目的spring–boot-dependenci es外，还有两个常用的版本依赖管理组件。
io.spring.platform适用于spr ing大家族。
spr ing-cloud-dependenci es适用于spr ing-cloud微服务框架。

 <dependency>
        <groupId>io.spring.platform</groupId>
        <artifactId>platform-bom</artifactId>
        <version>Cairo-SR8</version>
        <type>pom</type>
        <scope>import</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-dependencies</artifactId>
        <version>2020.0.0</version>
        <type>pom</type>
        <scope>import</scope>
    </dependency>