sbt 0.12.1 addresses several issues with dependency management. These fixes were made possible by specific, reproducible examples, such as a situation where the resolution cache got out of date (gh-532). A brief summary of the current work flow with dependency management in sbt follows.
update resolves dependencies according to the settings in a build
file, such as
resolvers. Other tasks use the
UpdateReport) to form various classpaths. Tasks
that in turn use these classpaths, such as
indirectly depend on
update. This means that before
compile can run,
update task needs to run. However, resolving dependencies on every
compile would be unnecessarily slow and so
update must be particular
about when it actually performs a resolution.
updatetask (as opposed to a task that depends on it) will force resolution to run, whether or not configuration changed. This should be done in order to refresh remote SNAPSHOT dependencies.
offline := true, remote SNAPSHOTs will not be updated by a resolution, even an explicitly requested update. This should effectively support working without a connection to remote repositories. Reproducible examples demonstrating otherwise are appreciated. Obviously, update must have successfully run before going offline.
skip in update := truewill tell sbt to never perform resolution. Note that this can cause dependent tasks to fail. For example, compilation may fail if jars have been deleted from the cache (and so needed classes are missing) or a dependency has been added (but will not be resolved because skip is true). Also, update itself will immediately fail if resolution has not been allowed to run since the last clean.
updateexplicitly. This will typically fix problems with out of date SNAPSHOTs or locally published artifacts.
last updatecontains more information about the most recent resolution and download. The amount of debugging output from Ivy is high, so you may want to use lastGrep (run help lastGrep for usage).
update. If this works, it could indicate a bug in sbt, but the problem would need to be reproduced in order to diagnose and fix it.
~/.ivy2/cacherelated to problematic dependencies. For example, if there are problems with dependency
"org.example" % "demo" % "1.0", delete
~/.ivy2/cache/org.example/demo/1.0/and retry update. This avoids needing to redownload all dependencies.
~/.ivy2/cache, especially if the first four steps have been followed. If deleting the cache fixes a dependency management issue, please try to reproduce the issue and submit a test case.
These troubleshooting steps can be run for plugins by changing to the build definition project, running the commands, and then returning to the main project. For example:
> reload plugins > update > reload return
offline := truein
~/.sbt/1.0.0-M5/global.sbt. A command that does this for the user would make a nice pull request. Perhaps the setting of offline should go into the output of about or should it be a warning in the output of update or both?
~/.ivy2/cache. Before doing this with 0.12.1, be sure to follow the steps in the troubleshooting section first. In particular, verify that a clean and an explicit update do not solve the issue.
changing()because sbt configures Ivy to know this already.