addSbtPlugin("org.hammerlab.sbt" % "versions" % "5.0.0")SBT plugin for setting and managing dependencies' versions; source.
Set the current project's version with a variety of short-hands:
// Set the version to "1.2.3-SNAPSHOT", or "1.2.3" if "snapshot" is true
v"1.2.3"
v("1.2.3")
// un-snapshot the versions set above
snapshot := falseThese work by setting the revision key, which then propagates to the version key.
The r ("release") syntax sets the version, presumably to an already-released value, and disables publish tasks:
r"1.2.3"This is useful if you want to publish some modules in a project that depend on other modules in the same project that you don't want to publish.
I use a command alias prep in my ~/.sbt/1.0/settings.sbt to set prepare all non-r"…" modules for release:
addCommandAlias("prep", "set snapshot in ThisBuild := false")- this un-snapshots all
v"…"modules, which are now eligible for release r"…"modules can be depended on by them, but will not be released themselves.
Then, to perform a release of certain modules in a project:
- set the desired modules' release versions using
v"…" - fix all other modules' versions with
r"…" - in the SBT repl:
prep +publishSigned sonatypeClose sonatypeRelease
The defaultVersions setting, and versions() helper, allow for setting versions for dependencies that may be used more than once in a project.
For example, a plugin can define {group,artifact} coordinates for common dependencies:
object MyPlugin extends AutoPlugin {
object autoImport {
val guava = "com.google.guava" ^ "gauva"
val scalatest = "org.scalatest" ^^ "scalatest"
}
}(cf. the parent module in this repo)
Then a downstream, multi-module project can just specify the versions for such dependencies:
default(
versions(
guava → "19.0",
scalatest → "3.0.0"
)
)
lazy val module1 = project.settings(dep(guava))
lazy val module2 = project.settings(dep(scalatest tests))
// override defaults
lazy val module3 = project.settings(
dep(
guava % "16.0.1",
scalatest % "3.0.4" tests
)
)hammerlab/spark-bam provides an example of this pattern, and the parent plugin in this repo provides many common dependency-aliases, including the two above.
Many shorthands for defining aliases and settings for groups of related dependencies.
Here's an example from parent:
object circe
extends Libs(
// this is a template for Maven coordinates of the modules defined with `lib` below
"io.circe" ^^ "circe" ^ "0.9.3"
) {
val core = lib
val generic = lib
val literal = lib
val parser = lib
}This enables depending on various circe modules via:
dep(
// alias for circe.core, since it was the first declared `lib` above
circe,
circe.generic
)Their (shared) version is also given its own setting:
versions(
circe → "0.9.2"
)
// equivalent
circe.version = "0.9.2"You can override the settings member of a Libs group like the above; here's an example from spark:
object spark
extends Libs(
("org.apache.spark" ^^ "spark" ^ "2.2.1") - scalatest
) {
val core = lib
val graphx = lib
val mllib = lib
val sql = lib
/**
* Add Spark dependencies and set the Scala version to 2.11.x
*/
override val settings: SettingsDefinition =
`2.11`.only ++
Seq(
Deps.dep(
spark.core provided,
spark.tests tests,
hadoop provided,
kryo
),
// This trans-dep creates a mess in Spark+Hadoop land; just exclude it everywhere by default.
excludeDependencies += ExclusionRule("javax.servlet", "servlet-api")
)
}This allows a top-level build.sbt declaration:
sparkThat adds the specified settings (see spark for more discussion; note also the scalatest exclusion in the coordinate-template, as another option).
Many plugins in thie repo use this DSL in interesting ways; feel free to explore!