SBT项目依赖传递中解析器未继承导致依赖无法获取问题

数据老陈

2026-5-19

解决SBT项目依赖传递的仓库解析问题

嘿，这个问题我太熟了——本质上是SBT不会自动传递依赖项目的解析器配置在搞鬼！

你原本可能以为，只要C配置了B的仓库，就能顺着B找到它依赖的A，但SBT的逻辑不是这样的：当C拉取依赖时，只会用自己resolvers列表里的仓库去查找所有依赖（包括B本身，以及B依赖的A）。你只给C加了B的仓库，而A存在于另一个独立的仓库里，自然会出现找不到A的报错。

下面给你几个实用的解决方案，按需选择：

方案一：直接给C添加所有依赖链需要的仓库
最简单直接的方式，在C的build.sbt里同时配置A和B的仓库：
```
resolvers ++= Seq(
  "Repo A" at "../nexus-url/.../a",
  "Repo B" at "../nexus-url/.../b"
)
```
这个方法适合依赖链不长的小项目，能快速解决问题。
方案二：发布B时把A的仓库信息嵌入POM
SBT默认不会将项目的解析器写入发布的POM文件，但我们可以修改配置让它包含这些信息。这样C在拉取B的时候，会自动从B的POM里读取到A的仓库地址，不用手动给C加A的仓库。
在B的build.sbt里添加以下配置，重新发布B到仓库即可：
```
publishMavenStyle := true
pomIncludeRepository := { _ => true }
```
注意：这个配置会把B里所有的解析器都写入POM，如果有私有仓库，要确保C能正常访问这些仓库地址。
方案三：统一使用团队的Nexus代理仓库
这是长期维护的最优解——搭建一个Nexus代理仓库，把A和B的仓库都设置成这个代理的源。之后所有项目（A、B、C）都只需要配置这个统一的代理仓库地址：
```
resolvers += "Team Nexus Proxy" at "../nexus-url/.../proxy-repo"
```
这样不管后续依赖链怎么扩展，都不用逐个添加仓库，所有依赖都会通过代理仓库自动查找，彻底避免这类问题。