§Managing library dependencies
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.
§Unmanaged dependencies
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.
§Managed dependencies
Play uses Apache Ivy (via sbt) to implement managed dependencies, so if you’re familiar with Maven or Ivy, you are already used to managed dependencies.
Most of the time you can simply list your dependencies in the build.sbt file.
Declaring a dependency looks like this (defining group, artifact and revision):
libraryDependencies += "org.apache.derby" % "derby" % "10.13.1.1"Or like this, with an optional configuration:
libraryDependencies += "org.apache.derby" % "derby" % "10.13.1.1" % "test"Multiple dependencies can be added either by multiple declarations like the above, or you can provide a Scala sequence:
libraryDependencies ++= Seq(
"org.apache.derby" % "derby" % "10.13.1.1",
"org.hibernate" % "hibernate-core" % "5.4.10.Final"
)Of course, sbt (via Ivy) has to know where to download the module. If your module is in one of the default repositories sbt comes with then this will just work.
§Getting the right Scala version with %%
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.13" % "0.9.1"Assuming the scalaVersion for your build is 2.13.2, the following is identical (note the double %% after "org.scala-tools"):
libraryDependencies += "org.scala-stm" %% "scala-stm" % "0.9.1"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.
§Resolvers
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.
Use the resolvers setting key to add your own resolver. For example:
resolvers += "sonatype snapshots".at("https://oss.sonatype.org/content/repositories/snapshots/")sbt can search your local Maven repository if you add it as a repository:
resolvers += (
"Local Maven Repository".at(s"file:///${Path.userHome.absolutePath}/.m2/repository")
)§Handling conflicts between dependencies
sbt has extensive documentation about how to manage conflict between your dependencies:
sbt: Dependencies Conflict Management
You can also use sbt-dependency-graph to have a better visualization of your dependency tree. See also our page about debugging sbt common problems.