ライブラリ依存性
https://github.com/harrah/xsbt/wiki/Getting-Started-Library-Dependenciesの訳(2011/10/28時点)
This page assumes you've read the earlier Getting Started pages, in particular .sbt build definition, scopes, and more about settings.
ライブラリへの依存は次の二つの方法で追加できる。
- libディレクトリに置かれたjarファイル。これは管理下に無い依存になる(unmanaged)
- ビルド定義にて指定され、自動ダウンロードされた管理された依存（managed)
管理外依存(unmanaged)
多くは、unmanagedではなくmanagedを使うだろうが、開始時にはunmanagedの方が簡単だ。
libディレクトリに必要なjarを入れると、それがプロジェクトのクラスパスに追加される。それだけだ。
test用のjar、つまりScalaCheck, specs, ScalaTest等をlibに入れることもできる。
lib中の依存はすべてのクラスパス（compile, test, run, console)に追加される。 その中の一つのクラスパスを変更したいなら、dependencyClassPath in CompileあるいはdependencyClassPath in Runtime等を調整する必要がある。~=を使って、以前のクラスパス値を取得し、いくつかのエントリを削除して新しいクラスパス値を設定することができる。
unmanagedな依存を使うために、build.sbtに追加することは何もないが、ただし libではないディレクトリを使用したい場合はunmanaged-baseキーを変更する必要があるだろう。
libではなくcustom_libを使うには以下のようにする
unmanagedBase <<= baseDirectory { base => base / "custom_lib" }baseDirectoryはプロジェクトのルートディレクトリを示すので、このようにbaseDirectory相対でunmanagedBaseを設定することができる。
unmanaged-baseディレクトリ中のjarをリストするunmanaged-jarsというタスクもある。 複数のディレクトリを使いたい場合や、他の複雑なことを実行したい場合、unmanaged-jarsタスクを何か別のものでまるまる置き換える必要が出てくるだろう。
管理依存(managed)
sbtは管理依存を実現するためにApache Ivyを使用している。 MavenやIvyに親しんでいるなら、問題はないだろう。
libraryDependenciesキー
librariDependenciesに君の依存をリストアップすることには、多くの時間を費やすことになるだろう。 依存を構成する他の方法として、MavenのPOMファイルやIvyのコンフィギュレーションファイルを使う方法もある。 この場合はsbtにそれらの外部コンフィギュレーションファイルを読みこませるようにするのだ。 ここで、その方法を教えるよ。
依存の宣言は以下のようになる。 groupId, ArtifactId, Revisionは実際には文字列だ。
libraryDependencies += groupID % artifactID % revision
あるいは、このようにする。configurationも実際には文字列だ。
libraryDependencies += groupID % artifactID % revision % configuration
libraryDependencies is declared in Keys like this:
val libraryDependencies = SettingKey[Seq[ModuleID]]("library-dependencies", "Declares managed dependencies.")%メソッドによってsettingからModuleIDオブジェクトが生成され、これをlibraryDependenciesに追加することができる。
当然だが、sbt(Ivyによる）はモジュールをどこからダウンロードすべきかを知っている。 もし、君の必要なモジュールが、sbtにビルトインされたリポジトリの一つにあるのなら、これはうまくいく。 例えば、Apache Derbyはデフォルトのリポジトリ中に存在するが、
libraryDependencies += "org.apache.derby" % "derby" % "10.4.1.3"
これをbuild.sbt注に記述して、updateすれば、sbtはDerbyをダウンロードして~/.ivy2/cache/org.apache.derby/に格納する。 (ところで、compileはupdateに依存しているので、多くの場合updateと入力する必要はない）
当然、++=を使って、複数の依存を一度に追加することができる。
libraryDependencies ++= Seq(
groupID % artifactID % revision,
groupID % otherID % otherRevision
)レアケースだが、librariDependenciesに対して、:=、<<=、+=等を使いたくなる場合もあるかもしれない。
%%を使って正しいScalaバージョンを取得する
「groupID % artifactID % revision」ではなく、「groupID %% artifactID % revision」を使った場合 （違いはgroupIDの後が、ダブルの%%になっていること）、sbtは君のプロジェクトのScalaバージョンをartifact名に追加する。 これは単なるショートカットだ。%%を使わないで明示的に記述してもいい。
libraryDependencies += "org.scala-tools" % "scala-stm_2.9.1" % "0.3"
君のビルドのscalaVersionが2.9.1の場合、以下のように記述しても同じことになる。
libraryDependencies += "org.scala-tools" %% "scala-stm" % "0.3"
複数のScalaバージョンに対応する依存（ライブラリ）が存在するので、君のプロジェクトにマッチするものを取得したいだろう。
実際にはそれほど話は簡単ではなく、しばしば別のScalaバージョンが必要なったりするのだが、%%はそれほど賢くはない。 依存ライブラリが2.9.0用に提供されており、しかし「scalaVersion := "2.9.1"」を使っているとすれば、%%を使うことはできない。If %% stops working just go see which versions the dependency is really built for, and hardcode the one you think will work (assuming there is one).
詳細は「Cross Build」を参照のこと。
訳注：Scalaはコンパイル済コードのバイナリ互換性がいまのところ無いため、対象とするScalaのバージョンによって別々のバイナリが用意されているのが普通。例えば、foobarのバージョン1.2というバイナリは、ただ一つではなく、scala2.8.0用の1.2、scala2.9.0用の1.2などという風に用意されている。
Ivyのリビジョン
「groupID % artifactID % revision」におけるrevisionは単一の固定したバージョンを持つわけではない。 Ivyは指定あｓれた制約に基づいた最新のリビジョンを選択することができる。 例えば、固定した "1.6.1"の代わりに、"latest.integration", "2.9.+", あるいは "[1.0,)"と指定することができる。
詳細は「Ivy revisions documentation」を参照のこと。
リゾルバ
すべてのパッケージが一つのサーバ上にあるわけではない。 sbtはデフォルトでは、標準的なMaven2リポジトリとScala Toolsリリース(http://scala-tools.org/repo-releases) リポジトリを使用する。もし、君の使いたい依存がデフォルトリポジトリに存在しないのであれば、それをIvyに探させるために、リゾルバを追加することができる。
リポジトリを追加するには、以下のようにする。
resolvers += name at location
例えば、
resolvers += "Scala-Tools Maven2 Snapshots Repository" at "http://scala-tools.org/repo-snapshots"
resolversキーは以下のように定義されている。
val resolvers = SettingKey[Seq[Resolver]]("resolvers", "The user-defined additional resolvers for automatically managed dependencies.")atメソッドは二つの文字列からResolverオブジェクトを生成する。
もしローカルなMavenリポジトリを使いたいのであれば、それをリポジトリとして追加する。
resolvers += "Local Maven Repository" at "file://"+Path.userHome.absolutePath+"/.m2/repository"
詳細は「Resolvers」を参照のこと。
デフォルトのリゾルバをオーバライドする
resolvers does not contain the default resolvers; only additional ones added by your build definition.
sbt combines resolvers with some default repositories to form external-resolvers.
Therefore, to change or remove the default resolvers, you would need to override external-resolvers instead of resolvers. Per-configuration dependencies
Often a dependency is used by your test code (in src/test/scala, which is compiled by the Test configuration) but not your main code.
If you want a dependency to show up in the classpath only for the Test configuration and not the Compile configuration, add % "test" like this:
libraryDependencies += "org.apache.derby" % "derby" % "10.4.1.3" % "test"
Now, if you type show compile:dependency-classpath at the sbt interactive prompt, you should not see derby. But if you type show test:dependency-classpath, you should see the derby jar in the list.
Typically, test-related dependencies such as ScalaCheck, specs, and ScalaTest would be defined with % "test".
Next
There are some more details and tips-and-tricks related to library dependencies on this page, if you didn't find an answer on this introductory page.
If you're reading Getting Started in order, for now, you might move on to read .scala build definition.