Note: Some sections of this page were copied from the sbt manual, specifically from the Library Dependencies page. You can refer to that page for a more detailed and updated version of the information here.

Most people end up using managed dependencies - which allows for fine-grained control, but unmanaged dependencies can be simpler when starting out.

Unmanaged dependencies work like this: create a lib/ directory in the root of your project and then add jar files to that directory. They will automatically be added to the application classpath. There’s not much else to it.

There’s nothing to add to build.sbt to use unmanaged dependencies, although you could change a configuration key if you’d like to use a directory different than lib.

If you use groupID %% artifactID % revision rather than groupID % artifactID % revision (the difference is the double %% after the groupID), sbt will add your project’s Scala version to the artifact name. This is just a shortcut. You could write this without the %%:

libraryDependencies += "org.scala-stm" % "scala-stm_2.11" % "0.8"

Assuming the scalaVersion for your build is 2.11.1, the following is identical (note the double %% after "org.scala-tools"):

libraryDependencies += "org.scala-stm" %% "scala-stm" % "0.8"

The idea is that many dependencies are compiled for multiple Scala versions, and you’d like to get the one that matches your project to ensure binary compatibility.

sbt uses the standard Maven2 repository and the Typesafe Releases (https://repo.typesafe.com/typesafe/releases) repositories by default. If your dependency isn’t on one of the default repositories, you’ll have to add a resolver to help Ivy find it.