Month: December 2014

Understanding sbt and sbt-web settings

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.

Builds

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

▸ Read more...

Posted in Scala & Playframwork