§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.
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
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
Declaring a dependency looks like this (defining
libraryDependencies += "org.apache.derby" % "derby" % "10.11.1.1"
Or like this, with an optional
libraryDependencies += "org.apache.derby" % "derby" % "10.11.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.11.1.1", "org.hibernate" % "hibernate-entitymanager" % "4.3.9.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-tools" % "scala-stm_2.11.1" % "0.3"
scalaVersion for your build is
2.11.1, the following is identical (note the double
libraryDependencies += "org.scala-tools" %% "scala-stm" % "0.3"
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.
resolvers setting key to add your own resolver.
resolvers += name at location
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 "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.
Next: Working with sub-projects
Found an error in this documentation? The source code for this page can be found here. After reading the documentation guidelines, please feel free to contribute a pull request. Have questions or advice to share? Go to our community forums to start a conversation with the community.