I have a .scala build definition set up as follows:
object build extends Build {
lazy val root = Project("main", file(".")) aggregate(benchmark)
lazy val benchmark = Project("benchmark", file("benchmark"))
}
I need to run re-start task on main project before running run task on benchmark (so I need to ensure that benchmark/run triggers main/re-start). Is there a way to specify such dependency?
EDIT: Seems I found the solution, so I will add it to this question in case somebody runs into the same problem. The idea is to create a custom version of reStart task, making it a Task instead of InputTask, since we don’t need to parse arguments. The full build.scala is as follows:
import sbt._
import Keys._
import cc.spray.revolver.RevolverPlugin.Revolver._
import cc.spray.revolver.Actions._
import cc.spray.revolver.AppProcess
object build extends Build {
val noArgs = TaskKey[ExtraCmdLineOptions]("no-args")
val noArgsTask = TaskKey[ExtraCmdLineOptions]("no-args") := { ExtraCmdLineOptions(Nil, Nil) }
val reStartCustom = TaskKey[AppProcess]("re-start-custom")
val reStartTask = reStartCustom <<= (streams, state, reForkOptions, mainClass in reStart, fullClasspath in Runtime, reStartArgs, noArgs in root)
.map(restartApp)
.updateState(registerAppProcess)
.dependsOn(products in Compile)
lazy val root: Project = Project("main", file("."), settings = Defaults.defaultSettings ++ Seq(noArgsTask, reStartTask)) aggregate(benchmark)
lazy val benchmark: Project = Project("benchmark", file("benchmark"), settings = Defaults.defaultSettings ++ Seq(
run in Compile <<= (reStartCustom in root, run in Compile in benchmark) {
case (mainRestart, benchmarkRun) =>
benchmarkRun.mapTask { runTask => mainRestart.flatMap(_ => runTask) }
}
))
}
There may be nicer ways to do it, but here is my take on it:
With this setup,
sbt "project benchmark" runwill first run therestarttask on themainproject, and then actually invoke the standardruncommand on projectbenchmark.Note that I added a
restartTaskKey (and a dummy implementation inmain) for illustration.As you can see, this looks a bit involved for such a simple requirement, but it is my (limited) experience that working with
InputTasks/InputKeys (runbeing one) is always much more tricky than it ought to be (as opposed to plainTasks/TaskKeys which are easier to handle).