解决dependency-analysis-gradle-plugin插件中的Guava版本冲突问题

问题背景

在使用dependency-analysis-gradle-plugin插件（版本2.1.3）时，开发者在执行buildHealth任务时遇到了一个严重错误。错误表现为computeAdvice任务执行失败，核心异常是NoSuchMethodError，提示找不到com.google.common.graph.Graphs.reachableNodes方法。

错误分析

这个错误表面上看是Guava库版本不兼容导致的。具体来说：

1. 插件内部使用了Guava的图算法功能，特别是Graphs.reachableNodes方法
2. 运行时环境中加载的Guava版本与插件编译时使用的版本不一致
3. 方法签名在不同版本间发生了变化，导致JVM无法找到预期的方法

根本原因

深入分析后发现，问题实际上源于Gradle插件管理方式的变化。开发者最初将插件配置从build.gradle.kts迁移到了settings.gradle.kts中，目的是为了解决Gradle的一个已知问题（关于插件版本管理的问题）。

这种迁移导致了：

1. Kotlin插件和dependency-analysis插件被定义在了不同的位置
2. 隐式引入了不同版本的Guava依赖
3. 类加载时出现了版本冲突

解决方案

开发者最终采取的解决方法是：

1. 统一使用"Build Health settings plugin"方式配置插件
2. 确保所有相关插件的依赖版本一致
3. 避免在多处重复定义插件

这种方法不仅解决了当前的Guava版本冲突问题，还使构建配置更加清晰和一致。

经验总结

这个案例给我们几个重要的启示：

1. 插件管理一致性：在Gradle项目中，插件的定义位置和方式需要保持一致，特别是在大型多模块项目中

2. 依赖冲突排查：当遇到NoSuchMethodError时，首先要考虑的是类路径中存在多个版本的同一依赖

3. 构建配置最佳实践：

   • 优先使用settings插件方式管理构建配置
   • 避免在build.gradle和settings.gradle中重复定义插件
   • 使用依赖约束确保传递依赖版本一致

4. 问题诊断技巧：

   • 通过dependencies任务检查实际解析的依赖版本
   • 使用--stacktrace和--debug参数获取更详细的错误信息
   • 对比工作配置和失败配置的差异

通过这个案例，我们不仅解决了具体的技术问题，更重要的是理解了Gradle插件管理和依赖解析的深层机制，这对构建稳定可靠的Gradle项目具有重要意义。