100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Programming

Setting Up Scala and sbt

A practical walkthrough of installing Scala, understanding sbt (the Scala Build Tool), and creating your first buildable project.

FoundationsBeginner9 min readJul 10, 2026
Analogies

Setting Up Scala and sbt

Before writing any Scala code, you need three pieces in place: a Java Development Kit (JDK, typically version 11 or 17), the Scala compiler and runtime, and sbt, the standard build tool used to manage dependencies, compile, test, and run Scala projects. The recommended path today is to install Coursier, a fast dependency resolver and installer, and let its cs setup command fetch a matching JDK, the Scala compiler, and sbt in one coordinated step rather than installing each component separately by hand.

🏏

Cricket analogy: Setting up Scala is like a franchise assembling its full squad and ground staff before a season starts — the JDK is the pitch itself, Coursier is the scouting network that brings in the right players (Scala compiler), and sbt is the team management software (BCCI's IPL auction system) that tracks who's signed and coordinates practice.

Installing the JDK and Scala with Coursier

Running cs setup from Coursier is the recommended first step: it downloads a matching JDK build (such as Eclipse Temurin), installs the scala and scalac commands, and adds sbt to your PATH, all version-checked to work together. Trying to install these pieces independently — an arbitrary JDK from one vendor, a Scala version from another download page — is a common source of confusing, hard-to-debug compatibility errors for newcomers.

🏏

Cricket analogy: Installing Scala via the Coursier (cs) launcher is like a young player going through the BCCI's centralized talent pipeline instead of ad hoc club trials — running cs setup fetches a matching JDK and the correct Scala compiler version in one coordinated process, much as the pipeline verifies eligibility and skill level before fast-tracking selection.

Understanding sbt: The Scala Build Tool

sbt itself is more than a command runner: it resolves your project's declared dependencies transitively from repositories like Maven Central, tracks which source files have changed since the last build, and recompiles only what's necessary through incremental compilation. sbt also manages multiple related tasks — compiling, running tests, packaging a jar, launching a REPL — as a single coherent workflow driven by one configuration file.

🏏

Cricket analogy: sbt managing your project's dependencies is like a franchise's team management software automatically tracking every player's contract, form, and availability across a season — sbt resolves library versions from Maven Central and recompiles only what changed, the way team management flags exactly which player needs rest before the next match.

Anatomy of a build.sbt File

A minimal build.sbt file declares four things: name (the project's identifier), version (the project's own release number), scalaVersion (which Scala compiler version to use), and libraryDependencies (a list of external libraries the project needs, each specified as an organization, artifact name, and version). Getting these declarations right matters: an incompatible scalaVersion or a library published for the wrong Scala binary version is one of the most common causes of build failures for beginners.

🏏

Cricket analogy: A build.sbt file's core settings — name, version, scalaVersion — are like a scorecard's header info: team name, match number, and format (Test, ODI, T20) that must be declared before a single ball is bowled, just as sbt needs these settings before it can compile anything.

scala
// build.sbt — the project's build definition
ThisBuild / scalaVersion := "3.3.1"

lazy val root = (project in file("."))
  .settings(
    name := "hello-scala",
    version := "0.1.0",
    libraryDependencies += "org.scalatest" %% "scalatest" % "3.2.18" % Test
  )

// From the terminal, inside the project directory:
// $ sbt compile   -> compiles all sources
// $ sbt run       -> compiles (if needed) and runs the main class
// $ sbt test      -> runs the test suite
// $ sbt console   -> opens a Scala REPL with your project's classpath loaded

sbt has an interactive shell: run sbt alone to enter it, then type compile, run, or ~compile (the tilde prefix watches your source files and recompiles automatically on every save) without restarting the JVM each time, which is much faster than invoking sbt compile fresh from the command line repeatedly.

A mismatch between your installed JDK version, the scalaVersion in build.sbt, and the sbt version in project/build.properties is one of the most common sources of confusing build failures for beginners — for example, some library binaries are only published for specific Scala binary versions (2.12 vs 2.13 vs 3), so always check a dependency's supported Scala version before adding it.

  • sbt (the Scala Build Tool) is the standard tool for compiling, testing, running, and packaging Scala projects.
  • Coursier's cs setup command is the recommended way to install a matching JDK, the Scala compiler, and sbt together.
  • A build.sbt file declares core settings: name, version, scalaVersion, and libraryDependencies.
  • sbt resolves dependencies transitively from repositories like Maven Central using Coursier resolution.
  • The sbt interactive shell (just running sbt) avoids relaunching the JVM for every command, and ~compile recompiles automatically on file changes.
  • Version mismatches between JDK, scalaVersion, and library artifacts are a common source of build errors.

Practice what you learned

Was this page helpful?

Topics covered

#Programming#ScalaStudyNotes#SettingUpScalaAndSbt#Setting#Scala#Sbt#Installing#StudyNotes#SkillVeris#ExamPrep