Question

sbt中一个相当新的“特征”，可能是0.13.7或0.13.8，是一种非常烦人的行为，不再能找到传递依赖。

例如。我有一个项目A依赖于库B版本1.25.1，它依赖于库C版本1.13.1。当然，只有库依赖关系B在A中定义，因为我不想定义几十个子库的整个树。好的，这就构建了。

现在我将A中的依赖项更新为库B版本1.25.2，而后者依赖于库C版本1.13.2。现在sbt抱怨相当无用的消息“在库-C中找不到配置; 1.13.2：'master'。它来自库-B; 1.25.2编译”，后跟一个< strong>“未解决的依赖”异常。 Sbt甚至懒得从Maven Central下载库C版本1.13.2，或者实际上发现它已经在本地发布。 “解决”这个问题的唯一方法是将库C版本1.13.2的依赖性添加到项目A中，这正是我不想做的。

以下是打印输出示例：

[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn]  ::          UNRESOLVED DEPENDENCIES         ::
[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn]  :: de.sciss#scalacolliderugens-core_2.11;1.13.2: configuration not found in de.sciss#scalacolliderugens-core_2.11;1.13.2: 'master'. It was required from de.sciss#scalacolliderswing-core_2.11;1.25.2 compile
[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn] 
[warn]  Note: Unresolved dependencies path:
[warn]      de.sciss:scalacolliderugens-core_2.11:1.13.2
[warn]        +- de.sciss:scalacolliderugens-plugins_2.11:1.13.2
[warn]        +- de.sciss:scalacolliderswing-core_2.11:1.25.2 (/home/hhrutz/Documents/devel/SoundProcesses/build.sbt#L167)
[warn]        +- de.sciss:soundprocesses-compiler_2.11:2.20.0-SNAPSHOT

我认为这是sbt中的一个令人讨厌的错误，或者是否有一些更深层次的推理背后无法解决我无法理解的传递依赖？

Answer 1

在我明确添加库C之后，问题甚至回来了。通常，最终的解决方案是：

$ rm -r ~/.ivy2/cache/
$ rm -r ~/.ivy2/local/

然后再次下载互联网。

在X /未解析（传递）依赖项中找不到新的sbt“feature”配置

1 个答案: