Question

我们有一个包含17个项目的SBT 0.13.0多项目构建：1个叶子项目，15个依赖于叶子（但不是彼此）的模块，以及1个依赖于15个模块的聚合器。

以下是Build.scala文件的概念：

val deps: Seq[Setting[_]] = Seq(libraryDependencies ++= Seq(
  "com.foo" % "foo" % "1.0.0",
  "com.bar" % "bar" % "1.0.0"
))

val leaf = Project("leaf").settings(deps:_*)

val module1 = Project("module1").dependsOn(leaf).settings(deps:_*)
val module2 = Project("module2").dependsOn(leaf).settings(deps:_*)
...
val module15 = Project("module15").dependsOn(leaf).settings(deps:_*)

val aggregator = Project("aggregator)".dependsOn(
  module1,
  module2,
  ...
  module15
).settings(deps:_*)

所有这些项目都将完全列为与libraryDependencies完全相同的外部依赖关系集。出于某种原因，当我们在聚合器中运行update命令时，每个项目大约需要一分钟（总共大约15分钟！），即使没有单一的新依赖项要解决或下载。

更糟糕的是，我们最近添加了一个依赖项，现在update命令导致SBT膨胀到~5GB内存，有时在解析期间完全挂起。我们如何调试这个？

我们尝试过YourKit对其进行分析，它可能是一个阅读鲱鱼，但到目前为止，我们唯一看到的是sbt.MultiLogger课程在BufferedOutputStream.flush电话中花费了大量时间。< / p>

Answer 1

如果您的某些外部依赖性实际上是您自己的库推送到本地存储库并且其版本设置为“最新”，那么这种挂起是预期的。原因是当需要“最新”版本时，常春藤会为所有依赖项尝试所有存储库。由于您的库未被推送到公共存储库，因此在公共存储库上检查它们会在超时时结束（显然这是一个常春藤问题）。

我尝试复制你的设置，并创建了一个带有叶子，15个模块，聚合器和一些外部依赖项的sbt项目。这一切都很快解决了。您可以在

查看

https://github.com/darkocerdic/sbt-multiproject-resolving

SBT挂起解决依赖关系

1 个答案: