Why does sbt not choose the most recent dependency version within range? - scala

Question

in a build.sbt we can declare a range for a dependency; for example:
libraryDependencies += groupID %% "mylib" % "[2.0,)"
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).
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:
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)

Answer 1

The problem (for once) does not seem to reside in 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]
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.
So the real problem seems to be that sbt publish to a nexus repository does not recreate the index in that repository.
Workaround
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