Integration with the Scala interpreter for rapid iteration and debugging
Support for mixed Java/Scala projects
sbt is the de facto build tool in the Scala community, used by the Lift web framework and Play Framework. Scala's commercial outlet, Lightbend Inc., has called sbt "arguably the best tool for building Scala projects", saying that its two most prominent features are incremental compilation and an interactive shell. When continuous compilation mode is entered, the Scala compiler is instantiated only once, which eliminates subsequent startup costs, and source file changes are tracked so that only affected dependencies are recompiled. The interactive console allows modifying build settings on the fly and entering the Scala REPL along with all class files of the project. The popularity of the incremental compilation has prompted Typesafe to extract this feature in the form of an independent component called Zinc. sbt had already fed back into the Scala standard library before, when its process API was adopted in Scala 2.9.
History
sbt was first publicly announced on 18 December 2008 by Mark Harrah — its original author. It was initially an abbreviation that stood for "Simple Build Tool", but it is now known simply as "sbt".
Build files
An sbt build can be defined using a .sbt file Below is an example of build.sbt build definition: val scalaTest = "org.scalatest" %% "scalatest" % "3.0.5" val akkaVersion = "2.4.2" val akkaActor = "com.typesafe.akka" %% "akka-actor" % akkaVersion val akkaCluster = "com.typesafe.akka" %% "akka-cluster" % akkaVersion // Set the Scala version used by this build to 2.12.8. ThisBuild / scalaVersion := "2.12.8" ThisBuild / version := "0.1.0-SNAPSHOT" ThisBuild / organization := "com.example" lazy val root = .aggregate .dependsOn .settings lazy val helloCore = .settings
Example use
sbt may be invoked for each build command, or it may enter interactive mode if no command is given. To clean build products of the current build: $ sbt clean
Multiple commands may be used on the same line. To run a single test named "Foo" and then publish exported jars: $ sbt "testOnly Foo" publish
Extensibility and integration
The functionality of sbt can be extended through a plugin architecture. A dedicated website was set up for community contributed plugins, which cover various areas such as signing, packaging, publishing and releasing artifacts, connecting to other services such as blogs and databases, or integrating with other technologies such as deploying to the Android platform. There are plugins to automatically create project files for the Eclipse and IntelliJ IDEA IDEs. On the other hand, an allows the sbt console to be integrated into IDEA, and projects can choose to use sbt for building.
Comparison and criticism
As with most software tools, sbt has found advocates and critics. It is often compared against Apache Maven, which is a standard build tool in the Java world. In particular, the domain-specific language used for sbt build files has attracted criticism as being cryptic compared to the pure declarative approach of Maven's XML files. Furthermore, an incompatible change in the file format and layout was introduced with the version jump from 0.7 to 0.10. Due to the maturity of Maven and sbt being rather young, it has also been said that Maven provides a greater number of plugins and that sbt's documentation is lacking, although others say that the quality of documentation is improving. The sbt project uses sbt to build itself, and considers that dogfooding is a positive feature. To the Debian project, however, that is considered a circular dependency, that they try to minimize. As a result, sbt is not yet in Debian.
