| sbt | |
| Author: | Mark Harrah |
| Developer: | Scala Center[1] |
| Latest Release Version: | 1.9.9[2] |
| Latest Release Date: | [3] |
| Programming Language: | Scala |
| Operating System: | Cross-platform |
| Platform: | Java |
| Genre: | Build automation |
| License: | BSD License |
sbt (originally Simple Build Tool, nowadays often believed to stand for Scala Build Tool or used as its own proper name[4]) is an open-source build tool created explicitly for Scala and Java projects. It aims to streamline the procedure of constructing, compiling, testing, and packaging applications, libraries, and frameworks. sbt is highly adaptable, permitting developers to customize the build process according to their project's specific needs.
sbt provides a wide range of features to make the process of building and managing Scala projects easy and efficient.[5] Some of the key features include:
sbt is the de facto build tool in the Scala community,[6] used, for example, by the Scala 2 and Scala 3 compilers themselves, Play Framework, and Lichess, a popular chess server. The sbt project is "bootstrapped" — it uses sbt to build itself and considers dogfooding a positive feature.
sbt was originally released as an open-source project by Mark Harrah in 2008.[7] Over the years, it has evolved significantly through numerous releases, each introducing new features, bug fixes, and enhancements. Here is an overview of the significant releases, along with the key changes and innovations they introduced:[8]
An sbt build can be defined using a .sbt file[15] Below is an example of build.sbt build definition:
// Set the Scala version used by this build to 2.13.10.ThisBuild / scalaVersion := "2.13.10"ThisBuild / version := "0.1.0-SNAPSHOT"ThisBuild / organization := "com.example"
lazy val root = (project in file(".")) .aggregate(helloCore) .dependsOn(helloCore) .settings(name := "Hello", // Add a single dependency, for tests. libraryDependencies += scalaTest % Test)
lazy val helloCore = (project in file("core")) .settings(name := "Hello Core", libraryDependencies += scalaTest % Test, // Add multiple dependencies. libraryDependencies ++= List(akkaActor, akkaCluster))
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:
Multiple commands may be used on the same line. To run a single test named "Foo" and then publish exported jars:
The functionality of sbt can be extended through a plugin architecture.[16] Community-contributed plugins cover areas such as signing, packaging, publishing and releasing artifacts, connecting to other services such as blogs and databases, or integrating with other technologies.
Both IntelliJ IDEA and VS Code support sbt through their Scala plugins. In both those IDEs, it is possible to create a new project with initial sbt build files, as well as if the project already includes an sbt build file, it can be used to generate the project's configuration for the given IDE.
The main alternatives for sbt among build tools are Gradle and Apache Maven, both established build tools for projects developed on the JVM platform. In the Scala ecosystem, another popular build tool is Mill.[17] The choice between sbt, Gradle, Apache Maven, and Mill, depends on the specific requirements of your project and your familiarity with the tools. If you're working primarily with Scala, sbt or Mill might prove a better fit, while if you're working with multiple languages or technologies, one of the other two may be a better choice.
| sbt | Gradle | Maven | Mill | ||
|---|---|---|---|---|---|
| Language and target audience | Specifically designed for Scala and Java projects. Offers features that cater to the unique needs of the Scala ecosystem. Sees the most frequent usage in Scala projects. | General-purpose, supporting multiple languages, including Java, Groovy, Kotlin, Scala, and more. Sees the most frequent usage in Java and Kotlin projects. | Used for Java projects but can also support other programming languages via plugins like Scala, Groovy, and Kotlin. Sees the most frequent usage in Java projects. | Primarily targets Scala, but it does have support for compiling Java code in mixed Scala/Java projects. Sees the most frequent usage in Scala projects and is particularly appealing to developers who value simplicity and predictability in their build tool. | |
| Build file syntax | Build files are written in Scala, leveraging Scala's expressiveness and type safety during build definition. | Build files can be written in either Groovy or Kotlin. Syntax tends to lean towards being more declarative. | Uses XML for writing Project Object Model (POM) files. Syntax is more verbose and declarative, favoring a standardized project structure and a convention over configuration. | Uses plain Scala for its build files. Its build definitions are written as Scala object definitions and the tasks are defined as methods within those objects. | |
| Incremental compilation | Features incremental compilation, compiling only the sections of the code that have changed and thus speeding up the development process. | Also supports incremental compilation for Java and Kotlin projects, but its capability for Scala incremental compilation is not as well developed as sbt | By default, it does not support incremental compilation. It can be enabled via plugins like scala-maven-plugin for Scala projects or the incremental compilation feature of java-compiler-plugin for Java projects. | Features incremental compilation. Additionally, uses aggressive caching of task outputs and isolated environments for each task, which further improves the speed and accuracy of builds. | |
| Extensibility and plugins | Offers an extensive plugin ecosystem, allowing developers to enlarge the build tool's functionality. | Due to its wider acceptance across numerous languages and platforms, Gradle's plugin ecosystem is more extensive and varied than sbt | Has a larger and more mature plugin ecosystem than sbt due to its extensive history and wide acceptance within the Java community. | Has a smaller plugin ecosystem than sbt, but supports extensibility in a different way: In Mill, you can define reusable modules and libraries directly in your build files, in plain Scala. You can also import and use third-party Scala libraries in your build files. | |
| Performance | Employs performance optimizations like incremental compilation and parallel task execution, but the results vary depending on project complexity and specific use cases. | Emphasizes performance, utilizing a daemon process running in the background to accelerate builds. | By default, it doesn't support incremental compilation, nor parallel execution. Both can be achieved using plugins and build tool options. | Supports incremental compilation and parallel execution. Is generally considered to take a more aggressive approach to caching, which often leads to faster incremental build times compared to sbt, especially for larger projects. | |
| Build lifecycle | Uses complex DSL (Domain Specific Language) for build definitions, offering more granular control over the build process. | Its DSL is simpler than sbt | Introduces a fixed build lifecycle consisting of well-defined phases such as compile, test, package, install, etc. Through this, Maven provides a consistent structure across projects but lacks flexibility. | Builds are defined in terms of tasks. Each task represents a unit of work in a build, like compiling a module, running tests, creating a package, etc. Tasks can depend on other tasks. Mill takes care of running the tasks in the right order. | |
| Community | Has an active, supportive community, primarily concentrated on the Scala programming language. | Its community is more extensive and diverse than sbt | Its community is larger and more diverse, addressing multiple programming languages and technologies. | Mill is an actively developed open-source project. The community around it is not as large or established as the community around sbt, but it is active and engaged and. |