Reputation: 11244
On my local machine I have an ivy cache that has been filled by working on multiple projects.
A library X
is loaded using resolver Y
in project A
. This same library X
is used in project B
, no problems resolving this library because it's in my local cache.
When one of my colleagues loads project B
he get's the error that library X
could not be resolved. The problem: resolver Y
is missing.
How can I test if my sbt project has a complete set of resolvers to resolve all dependencies without removing my ivy cache?
Upvotes: 8
Views: 1294
Reputation: 476
There is now an SBT plugin available, called SBT dirty money, to add additional functionality for tackle this problem. Although you have to execute an extra command.
Upvotes: 1
Reputation: 11244
This command allows you to find if you are missing any updates for the current project. Note that this will not discover any missing resolvers for your plugins.
commands += Command.command("testUpdate") { state =>
val base = baseDirectory.value
val newState = Project
.extract(state)
.append(Seq(ivyPaths := new IvyPaths(base, Some(base / "tmp-cache"))), state)
val (s, _) = Project
.extract(newState)
.runTask(update, newState)
s
}
It could be expanded by removing the directory afterwards.
Upvotes: 2
Reputation: 2289
Another even more elegant solution would be to investigate the SBT sources if it is easily possible to setup this behavior as a separate task. The necessary steps could be the same as in my other answer.
sbt.ivy.home
from update
task and provide a parameterized overload for it (if this is possible)Upvotes: 2
Reputation: 2289
I found an admittedly simple but also a bit hacky and nonetheless working solution.
As described here you can setup the ivy home directory.
After setting this up it will provoke the sbt instances on your system to update all dependencies, due to a fresh cache directory.
When all dependencies could be resolved you could inspect the std out for some string indicating success. Like Done updating.
and delete the temporal folder afterwards. Caution, a fresh resolve from scratch might take a while! ~5min 100mBit/s and using an SSD drive
Instead of defining the sbt.ivy.home
variable system wide and in an somewhat unportable fashion i would recommend to use the less system invasive option of defining the sbt.ivy.home
variable within the environment variable SBT_OPTS
on your local command/terminal session. On Windows this looks as follows:
C:\Users\isi\Projects\learning\sbt-test-dependencies>SET SBT_OPTS=-Dsbt.ivy.home="C:\path\to\your\temp\directory"
C:\Users\isi\Projects\learning\sbt-test-dependencies>sbt
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
[info] Loading project definition from C:\Users\isi\Projects\learning\sbt-test-dependencies\project
[info] Updating {file:/C:/Users/isi/Projects/learning/sbt-test-dependencies/project/}sbt-test-dependencies-build...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] downloading https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/com.typesafe.sbteclipse/sbteclipse-plugin/scala_2.10/sbt_0.13/4.0.0/jars/sbteclipse-plugin.jar ...
[info] [SUCCESSFUL ] com.typesafe.sbteclipse#sbteclipse-plugin;4.0.0!sbteclipse-plugin.jar (4783ms)
...
[info] downloading https://jcenter.bintray.com/org/scala-lang/jline/2.10.5/jline-2.10.5.jar ...
[info] [SUCCESSFUL ] org.scala-lang#jline;2.10.5!jline.jar (419ms)
[info] downloading https://jcenter.bintray.com/org/fusesource/jansi/jansi/1.4/jansi-1.4.jar ...
[info] [SUCCESSFUL ] org.fusesource.jansi#jansi;1.4!jansi.jar (325ms)
[info] Done updating.
[info] Set current project to sbt-test-dependencies (in build file:/C:/Users/isi/Projects/learning/sbt-test-dependencies/)/Users/isi/Projects/learning/sbt-test-dependencies/)
The output can be piped to lets say grep
and the exit code can be used for further processing. Notice, that the console output above was produced using the interactive sbt
command, a similar output is generated using the non interactive sbt update
command.
Upvotes: 1