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

2
votes

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)
1
scalasbt

1 Answers

2
votes

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