具有非语义版本号的Sbt依赖关系

如果分支机构名称中有代码 feature/issue-123-frobulate ,我们的CI系统将发布一个包含版本的jar issue-123-SNAPSHOT 。我们的大部分代码都是内置的 mvn ,在这种情况下,您将pom更新为具有 <version>issue-123-SNAPSHOT</version> 它拉入分支代码。

我们开始添加使用sbt构建的Scala代码。的相关部分 build.sbt 有

libraryDependencies ++= Seq(
    "com.example" % "lib-being-developed" % "issue-123-SNAPSHOT",
    "com.example" % "other-lib" % "3.4.5"
)

哪里 other-lib 依赖于 lib-being-developed 版本2.14.0。

如果我跑步 sbt dependencyTree , 正在开发lib 显示两次,一次作为直接依赖项,一次是的子项 其他lib 。在这两种情况下,版本均为2.14.0。如果我评论掉对的依赖 其他lib , sbt依赖树 将版本显示为 issue-123-SNAPSHOT 。

我找不到关于如何 sbt 处理非语义版本,但在这种情况下, issue-123-SNAPSHOT 被认为是低于2.14.0的版本。

有没有办法告诉你 sbt 使用 issue-123-SNAPSHOT 版本,即使存在另一个依赖项使用的“更高”版本?我希望有这样的东西

   "com.example" % "lib-being-develop" % "issue-123-SNAPSHOT" :: USE_THIS_VERSION

我知道有一种方法可以排除的传递依赖关系 其他lib ,但出于几个原因,如果可以的话,我想避免这样做。

1. 这是一个暂时的变化,而一切都在发展中,我们最终会变回 "com.example" % "lib-being-develop" % "2.14.1" ,此时要撤消的更改是作为新版本更新的示例位置。
2. 依赖关系可能会出现好几次,所以我需要弄清楚哪些依赖关系是个问题,然后解决所有问题。

可以更改CI系统以发布类似语义版本的内容,例如 2.14.0.issue-123-SNAPSHOT ,但这是在另一个团队的控制下进行的,因此这种改变需要付出不小的努力,主要是说服其他人这是一个好主意,并对期望当前版本风格的员工进行再培训。