Inside sbt-web: Part II – Understanding sbt and sbt-web’s settings
Just enough sbt
If we want to talk about sbt-web, we must first discuess a few concepts related to sbt itself1. sbt is the Scala Build Tool, often critized for being overly complex. It however enables a lot of interesting use cases, so one might argue its not incidental but domain-related complexity2.
Let’s first look at the abstractions sbt provides and then go on to understand how sbt-web builds on them.
A build definition corresponds to the project you’re building. Each build can consist of multiple sub-builds, with one being the root project, or root build. Each project contains a top-level build file,
build.sbt, that corresponds to the root build.
.sbt files allow a subset of Scala syntax, and are compiled by sbt to Scala files. Alternatively you can write Scala build files directly (all build-related Scala files go into the
project folder), but with the recent additions to sbt, this is rarely needed.
If you don’t provide a build file, sbt will infer a standard build for you.
A typical project might look like this:
my-project/ build.sbt < -- root build file project/ <-- definitions for all sub-projects build.properties <-- define sbt version plugins.sbt <-- sbt plugins Common.scala <-- common build code my-domain-model <-- sub-project build.sbt <-- sub-project build file src/main/scala/... <-- sources my-play-web-ui build.sbt app conf my-play-admin-web-ui build.sbt app conf