sbt (software)

For SBT accounting software, see ACCPAC. For the television network, see Sistema Brasileiro de Televisão.

sbt

Original author(s)	Mark Harrah
Developer(s)	Scala Center
Stable release	1.10.5 / November 3, 2024 (2024-11-03)
Repository	github.com/sbt/sbt
Written in	Scala
Operating system	Cross-platform
Platform	Java
Type	Build automation
License	BSD License
Website	scala-sbt.org

sbt (originally simple build tool, nowadays stands for nothing) is an open-source build tool which can build Java, Scala, and Kotlin 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. Some of the key features include:

• Dependency management: Through its capacity to automatically download and handle project dependencies, sbt facilitates the usage of external libraries and frameworks.
• Incremental compilation':' sbt can recompile only parts of the code that have changed, resulting in significant time-saving during the development cycle.
• Customizable build process: sbt is highly customizable, allowing developers to define custom build settings and configure the build process to align with the unique requirements of their projects.
• Plugin ecosystem: sbt boasts a plugin ecosystem that enhances its functionality, incorporating extra features such as code quality checks, deployment automation, and test coverage reports. The development and integration of new plugins is fully supported and encouraged.
• Continuous compilation and testing: With sbt, developers can set the system to automatically recompile and rerun tests whenever a source file is altered.
• Multi-project builds: For developers working on multiple Scala projects, sbt offers helpful features to manage them within a single build.
• Interactive shell: sbt comes equipped with an interactive shell, providing developers with a convenient method to execute tasks and commands throughout the development process.
• Parallel task execution: sbt can execute tasks in parallel, speeding up build times for large projects.
• Integration with IDEs: To optimize the development experience, sbt integrates smoothly with popular Integrated Development Environments (IDEs), such as IntelliJ IDEA and Visual Studio Code.

sbt is the de facto build tool in the Scala community, 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.

History

sbt was originally released as an open-source project by Mark Harrah in 2008. 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:

1. sbt 0.3.2 (2008): This was the first official release of sbt. It introduced rudimentary features such as project definition, dependency management, and compilation.
2. sbt 0.7 (2009): Established the basic framework for constructing and managing Scala projects. Key features included incremental compilation, dependency management, and straightforward task execution.
3. sbt 0.10 (2011): Introduced a significant overhaul of the build definition syntax, making it more expressive and flexible. There were also enhancements in performance, dependency management, and configuration.
4. sbt 0.12 (2012): Improved support for multi-module projects, the ability to define custom configurations, and simplified plugin development.
5. sbt 0.13 (2013): Focused on usability and performance. This version introduced Activator, a web-based tool for creating and managing projects. Other features included incremental macro compilation, improved handling of build definition errors, and various performance optimizations. 0.13 remained the main sbt version for the next four years.
6. sbt 1.0 (2017): Introduced substantial changes to the sbt codebase, focusing on performance and stability, but also attempted to maintain compatibility with older versions as much as possible. New features included unified slash syntax for defining tasks and settings, improved dependency management, and Scala 2.12 as the language version used for build definitions. Furthermore, the switch to the new Zinc 1.0 incremental compiler further boosted incremental compilation performance.
7. sbt 1.1 (2018): This release launched the sbt server, enabling IDEs and other tools to interact with sbt via the Language Server Protocol (LSP). It also added cross-building support for Scala.js and Scala Native and improved the performance of various tasks.
8. sbt 1.3 (2019): This version significantly improved the user experience by speeding up dependency resolution by adopting Coursier as the default dependency manager. Further enhancements included improvements to the build caching mechanism and support for JDK 11.
9. sbt 1.5 (2021): Added support for Scala 3. Enhancements were also made to the BSP (Build Server Protocol) support, enabling better integration with IDEs.
10. sbt 1.8 (2022): This release brought updates to Coursier and improved Ivy support.
11. sbt 1.9 (2023): More updates to Coursier and a text-based menu to help with creating new projects.

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.2.14"
val akkaVersion = "2.6.20"
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.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)
  )

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. 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.

Comparisons

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. 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's.	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's.	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's, more declarative and may feel more intuitive for beginners.	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's, focusing on various programming languages and technologies.	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.

See also

• List of build automation software

External links

• Official website