sbt functions quite differently to the way many traditional build tasks. Fundamentally, sbt is a task engine. Your build is represented as a tree of task dependencies that need to be executed, for example, the compile task depends on the sources task, which depends on the sourceDirectories task and the sourceGenerators task, and so on.

sbt breaks typical build executions up into very fine grained tasks, and any task at any point in the tree can be arbitrarily redefined in your build. This makes sbt very powerful, but also requires a shift in thinking if you’ve come from other build tools that break your build up into very coarsely grained tasks.

The documentation here describes Play’s usage of sbt at a very high level. As you start to use sbt more in your project, it is recommended that you follow the sbt tutorial to get an understanding for how sbt fits together. Another resource that many people have found useful is this series of blog posts.

The name line defines the name of your application and it will be the same as the name of your application’s root directory, /. In sbt this is derived from the argument that you gave to the sbt new command.

The version line provides the version of your application which is used as part of the name for the artifacts your build will produce.

SBT is also able to construct the build requirements from scala files inside your project’s project folder. The recommended practice is to use build.sbt but there are times when using scala directly is required. If you find yourself, perhaps because you’re migrating an older project, then here are a few useful imports:

Found an error in this documentation? The source code for this page can be found here. After reading the documentation guidelines, please feel free to contribute a pull request. Have questions or advice to share? Go to our community forums to start a conversation with the community.