Perhaps this somehow folds within existing open and closed issues about libraryDependencies but I've not been successful at figuring that out. It seems that the code below, which attempts to modify the libraryDependencies per sub-project from within an AutoPlugin ― will not have any impact.
private def inject(): State => State = { state =>
val extracted: Extracted = Project.extract(state)
val enrichedLibDepSettings = extracted.structure.allProjectRefs map { projRef =>
val projectScalaVersion = (scalaBinaryVersion in projRef)
libraryDependencies in projRef +=
compilerPluginOrg % (compilerPluginArtifact + "_" + projectScalaVersion.value) % compilerPluginVersion % "provided"
}
val newState = extracted.append(enrichedLibDepSettings, state)
val updateAfterLibAppend = extracted.structure.allProjectRefs map { projRef =>
println("running update: " + EvaluateTask(extracted.structure, update, newState, projRef)) }
state
}
The importance is this would allow sbt plugins to inject a correct binary version of whatever, per sub-project ― thus providing significant gain to tooling ― such as enabling sbt plugins to inject a compiler plugin compatible to the binary version of every and each sub-project of a build, automatically.
Maybe I am missing something trivial about this configuration (haven't gotten @jsuereth's book yet) or it is something real about how library dependencies play out in sbt. Interestingly to me, scalacOptions are easy to set per project, using the same technique exemplified above. I hope I have laid out the entire case in this StackOverflow question. I'd be very thankful for your advice and would be able to provide a minimally reproducing repo for investigation.
From an arbitrary sample of well known projects in the wild, I gather that many projects (Play Framework, Akka, Parboiled2...), will require this above to work, in order to instrument them through a single sbt plugin. Apologies again if I have missed the obvious on solving it, in which case it's not actually a bug nor enhancement.
Perhaps this somehow folds within existing open and closed issues about
libraryDependencies
but I've not been successful at figuring that out. It seems that the code below, which attempts to modify thelibraryDependencies
per sub-project from within anAutoPlugin
― will not have any impact.The importance is this would allow sbt plugins to inject a correct binary version of whatever, per sub-project ― thus providing significant gain to tooling ― such as enabling sbt plugins to inject a compiler plugin compatible to the binary version of every and each sub-project of a build, automatically.
Maybe I am missing something trivial about this configuration (haven't gotten @jsuereth's book yet) or it is something real about how library dependencies play out in sbt. Interestingly to me,
scalacOptions
are easy to set per project, using the same technique exemplified above. I hope I have laid out the entire case in this StackOverflow question. I'd be very thankful for your advice and would be able to provide a minimally reproducing repo for investigation.From an arbitrary sample of well known projects in the wild, I gather that many projects (Play Framework, Akka, Parboiled2...), will require this above to work, in order to instrument them through a single sbt plugin. Apologies again if I have missed the obvious on solving it, in which case it's not actually a bug nor enhancement.