为什么 sbt 不选择范围内的最新依赖版本? [英] Why does sbt not choose the most recent dependency version within range?

问题描述

在build.sbt中，我们可以为依赖声明一个范围；例如:

in a build.sbt we can declare a range for a dependency; for example:

libraryDependencies += groupID %% "mylib" % "[2.0,)"

有(就我而言)有多个软件包在此范围内(我有 2.0.2、2.0.3、2.0.4 甚至一些更奇特的版本，例如 2.0.1.dev 和 2.0.3-devmylib 在我的存储库中可用).

There are (in my case) multiple packages that fall within this range (I have 2.0.2, 2.0.3, 2.0.4 and even some more exotic versions like 2.0.1.dev and 2.0.3-dev of mylib available in my repository).

当我尝试构建这个项目时，sbt 无缘无故地选择了 2.0.2 版本.我希望他取范围内最大的数字，但他从来没有.以下是我尝试过的要求和他选择的版本(因此只有在指定确切的版本号时，他才会选择更新的版本):

When I try to build this project, sbt consequently chooses version 2.0.2 for no apparent reason. I would expect him to take the biggest number within the range, but he never does. Here are the requirements I tried and the version he selected (so only when specifying an exact version number does he select a more recent version):

revision range      |    version selected
-----------------------------------------
[2.0,)              |    2.0.2
[2.0.0,)            |    2.0.2
]2.0,)              |    2.0.2
2.0.+               |    2.0.2
latest.integration  |    2.0.2
2.0.3               |    2.0.3
2.0.4               |    2.0.4

我已经尝试了以下解决方法:

I have already tried the following workarounds:

• 删除本地~/.sbt 和~/.ivy2 目录
• 运行 sbt -no-share -sbt-dir/tmp/sbt -ivy-dir/tmp/ivy 以避免任何缓存效果
• 在我的主目录中搜索名称中包含 mylib 的任何文件；只找到 ind ~/.ivy2
• 我使用 sbt 0.13.16 运行了大部分测试，但我尝试使用 0.13.15 和 0.13.17
• 请注意，我的所有构建每次都在我的 git 存储库的干净克隆中运行；所以没有目标目录保留.
• mylib 的 2.0.2、2.0.3 和 2.0.4 版本包含相同的代码和依赖项(我重新发布它们是为了测试)

• removing the local ~/.sbt and ~/.ivy2 directories
• running sbt -no-share -sbt-dir /tmp/sbt -ivy-dir /tmp/ivy to avoid any caching effect
• searching my home directory for any file containing mylib in the name; only found ind ~/.ivy2
• I have run most of my tests with sbt 0.13.16, but I have tried with 0.13.15 and 0.13.17
• Note that all my builds run each time in a clean clone of my git repository; so no target directory remains.
• the versions 2.0.2, 2.0.3 and 2.0.4 of mylib contain the same code and dependencies (I republished them for testing purposes)

推荐答案

问题(一次)似乎不存在于 sbt.

The problem (for once) does not seem to reside in sbt.

我尝试了 sbt 1.2.1 和范围 2.1.x.现在sbt抱怨找不到这个依赖；他列出了可用的版本:

I tried with sbt 1.2.1 and range 2.1.x. Now sbt complains that he cannot find this dependency; and he lists the available versions:

[warn] ==== my-maven-repo: tried
[warn] http://my-server/nexus/repository/my-repo/eu/company/mylib_2.12/[revision]/mylib_2.12-[revision].pom
[warn]   [2.0.2, 2.0.2-dev.20180719.16.55.39.develop.dc3a706, 2.0.1-dev.20180719.16.49.57.develop.dc3a706, 2.0.1-dev.20180719.16.42.31.develop.dc3a706, 2.0.1.dev.20180719.16.31.59.develop.dc3a706]

奇怪的是，他没有列出我的 nexus-maven 存储库中可用的所有软件包.使用nexus界面删除一个包后；此列表现在似乎已完成.

so strangely he does not list all packages available on my nexus-maven repository. After deleting one package using the nexus interface; it seems like this list was now complete.

所以真正的问题似乎是sbt publish到nexus存储库不会在该存储库中重新创建索引.

So the real problem seems to be that sbt publish to a nexus repository does not recreate the index in that repository.

我创建了一个自定义 sbt-publish-wrapper 脚本来强制 nexus 在发布新库时重新创建存储库元数据:

I have created a custom sbt-publish-wrapper script to force nexus to recreate the repository metadata when publishing a new library:

#!/bin/bash
set -e
# just run sbt publish with the passed arguments as-is
sbt $@ publish
# now make sure the repository on nexus is re-indexed
# this triggers a task to recreate metadata for all maven repositories. This task was manually configured in nexus.
# the id was obtained running `curl -v -u admin:***** -X GET http://my-company/nexus/service/rest/v1/tasks`
# the recreate-maven-repos needs only the nx-tasks-run privilege
curl -q -u recreate-maven-repos:recreate -X POST http://my-company/nexus/service/rest/v1/tasks/c42ab5f5-4bd6-4ed3-b2f1-d061c24a9b90/run

这篇关于为什么 sbt 不选择范围内的最新依赖版本?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！