ライブラリ管理に関する入門ページができたので、先にそちらを読むとよいかもしれません。
ドキュメントメンテナンスに関する注記: このページと入門ページの重複をなくし、このページにはチェックサムや外部 Ivy ファイルなどのより高度なトピックを残すのが良いでしょう。
sbt でライブラリを管理するには、手動と自動の 2 つの方法があります。これらの 2 つの方法は組み合わせることもできます。このページでは、2 つのアプローチについて説明します。ここで示されているすべての設定は、.sbt ファイルに直接記述する設定です。
依存関係を手動で管理するには、使用するすべての jar を `lib` ディレクトリにコピーします。 sbt は、コンパイル、テスト、実行、インタプリタの使用時に、これらの jar をクラスパスに追加します。このディレクトリにある jar の追加、削除、更新、その他の管理は、ユーザーの責任で行ってください。jar を格納するディレクトリの場所を変更しない限り、この方法を使用するためにプロジェクト定義を変更する必要はありません。
jar が格納されているディレクトリを変更するには、プロジェクト定義の `unmanagedBase` 設定を変更します。たとえば、`custom_lib/` を使用するには
unmanagedBase := baseDirectory.value / "custom_lib"
より詳細な制御と柔軟性が必要な場合は、最終的に sbt に手動の依存関係を提供する `unmanagedJars` タスクをオーバーライドします。デフォルトの実装は、おおよそ次のとおりです。
Compile / unmanagedJars := (baseDirectory.value ** "*.jar").classpath
デフォルトのディレクトリに加えて、複数のディレクトリから jar を追加する場合は、次のことができます。
Compile / unmanagedJars ++= {
val base = baseDirectory.value
val baseDirectories = (base / "libA") +++ (base / "b" / "lib") +++ (base / "libC")
val customJars = (baseDirectories ** "*.jar") +++ (base / "d" / "my.jar")
customJars.classpath
}
パスの構築の詳細については、パスを参照してください。
この依存関係管理方法は、プロジェクトの直接の依存関係を指定し、sbt に依存関係の取得と更新を処理させるというものです。
sbt 1.3.0+ は、依存関係管理に Coursier を使用しています。sbt 1.3.0 までは、sbt は 10 年間 Apache Ivy を使用していました。 Coursier は互換性を維持するのに優れていますが、一部の機能は Apache Ivy に固有のものがあります。そのような場合、次の設定を使用して Ivy に切り替えることができます。
ThisBuild / useCoursier := false
インライン宣言は、自動的に取得される依存関係を指定する基本的な方法です。Ivy を使用した完全な設定に代わる軽量な方法として意図されています。
依存関係の宣言は次のようになります。
libraryDependencies += groupID % artifactID % revision
または
libraryDependencies += groupID % artifactID % revision % configuration
設定マッピングの詳細については、設定を参照してください。また、複数の依存関係をまとめて宣言することもできます。
libraryDependencies ++= Seq(
groupID %% artifactID % revision,
groupID %% otherID % otherRevision
)
sbt でビルドされた依存関係を使用している場合は、最初の `%` を `%%` に2倍にします。
libraryDependencies += groupID %% artifactID % revision
これにより、現在使用している Scala のバージョンでビルドされた依存関係に適した jar が使用されます。この種の依存関係の解決中にエラーが発生した場合は、その依存関係が使用している Scala のバージョン用に公開されていない可能性があります。詳細については、クロスビルドを参照してください。
Ivy は、指定した制約に従ってモジュールの最新リビジョンを選択できます。` "1.6.1" ` のような固定リビジョンではなく、` "latest.integration" `、` "2.9.+" `、または ` "[1.0,)" ` を指定します。詳細については、Ivy リビジョンのドキュメントを参照してください。
sbt はデフォルトで標準の Maven2 リポジトリを使用します。
追加のリポジトリは、次の形式で宣言します。
resolvers += name at location
例えば
libraryDependencies ++= Seq(
"org.apache.derby" % "derby" % "10.4.1.3",
"org.specs" % "specs" % "1.6.1"
)
resolvers += "Sonatype OSS Snapshots" at "https://oss.sonatype.org/content/repositories/snapshots"
ローカル Maven リポジトリをリポジトリとして追加すると、sbt はそれを検索できます。
resolvers += "Local Maven Repository" at "file://"+Path.userHome.absolutePath+"/.m2/repository"
他のタイプのリポジトリの定義の詳細については、リゾルバーを参照してください。
`resolvers` は、追加のインラインユーザーリゾルバーを設定します。デフォルトでは、`sbt` はこれらのリゾルバーをデフォルトのリポジトリ (Maven Central とローカル Ivy リポジトリ) と組み合わせて `externalResolvers` を形成します。リポジトリをより詳細に制御するには、`externalResolvers` を直接設定します。通常のデフォルトに加えてリポジトリのみを指定するには、`resolvers` を設定します。
たとえば、デフォルトのリポジトリに加えて Sonatype OSS Snapshots リポジトリを使用するには、
resolvers += "Sonatype OSS Snapshots" at "https://oss.sonatype.org/content/repositories/snapshots"
Maven Central リポジトリではなく、ローカルリポジトリを使用するには
externalResolvers := Resolver.combineDefaultResolvers(resolvers.value.toVector, mavenCentral = false)
sbt、Scala、プラグイン、およびアプリケーションの依存関係を取得するために使用されるリポジトリは、グローバルに設定し、ビルドまたはプラグイン定義で設定されたリゾルバーをオーバーライドするように宣言できます。2つのパートがあります。
ランチャーが使用するリポジトリは、`~/.sbt/repositories` を定義することでオーバーライドできます。これには、`Launcher` 設定ファイルと同じ形式の `[repositories]` セクションが含まれている必要があります。例えば
[repositories]
local
my-maven-repo: https://example.org/repo
my-ivy-repo: https://example.org/ivy-repo/, [organization]/[module]/[revision]/[type]s/[artifact](-[classifier]).[ext]
リポジトリファイルの別の場所は、sbt 起動スクリプトの `sbt.repository.config` システムプロパティで指定できます。最後のステップは、`sbt.override.build.repos` を true に設定して、これらのリポジトリを依存関係の解決と取得に使用することです。
プロジェクトでリポジトリに存在しない依存関係が必要な場合は、その jar への直接 URL を次のように指定できます。
libraryDependencies += "slinky" % "slinky" % "2.1" from "https://slinky2.googlecode.com/svn/artifacts/2.1/slinky.jar"
URL は、設定されたリポジトリを介して依存関係が見つからない場合のフォールバックとしてのみ使用されます。また、明示的な URL は公開されたメタデータ (pom または ivy.xml) には含まれません。
デフォルトでは、これらの宣言はすべてのプロジェクトの依存関係を推移的に取得します。場合によっては、プロジェクトにリストされている依存関係がビルドに必要ないことがあります。たとえば、Felix OSGI フレームワークを使用するプロジェクトは、コンパイルと実行にメイン jar のみが明示的に必要です。この例のように、`intransitive()` または `notTransitive()` を使用してアーティファクトの依存関係を取得しないようにしてください。
libraryDependencies += "org.apache.felix" % "org.apache.felix.framework" % "1.8.0" intransitive()
`classifier` メソッドを使用して、依存関係の classifier を指定できます。たとえば、TestNG の jdk15 バージョンを取得するには
libraryDependencies += "org.testng" % "testng" % "5.7" classifier "jdk15"
複数の classifier の場合は、複数の `classifier` 呼び出しを使用します
libraryDependencies +=
"org.lwjgl.lwjgl" % "lwjgl-platform" % lwjglVersion classifier "natives-windows" classifier "natives-linux" classifier "natives-osx"
すべての依存関係に対して特定の classifier を推移的に取得するには、`updateClassifiers` タスクを実行します。デフォルトでは、これは `sources` または `javadoc` classifier を持つすべてのアーティファクトを解決します。`transitiveClassifiers` 設定を設定して、取得する classifier を選択します。たとえば、ソースのみを取得するには
transitiveClassifiers := Seq("sources")
依存関係の特定の推移的な依存関係を除外するには、excludeAllメソッドまたはexcludeメソッドを使用します。excludeメソッドは、プロジェクトのpomを公開する場合に使用します。除外する組織名とモジュール名が必要です。例えば、
libraryDependencies +=
"log4j" % "log4j" % "1.2.15" exclude("javax.jms", "jms")
excludeAllメソッドはより柔軟ですが、pom.xmlで表現できないため、pomを生成する必要がない場合にのみ使用してください。例えば、
libraryDependencies +=
"log4j" % "log4j" % "1.2.15" excludeAll(
ExclusionRule(organization = "com.sun.jdmk"),
ExclusionRule(organization = "com.sun.jmx"),
ExclusionRule(organization = "javax.jms")
)
APIの詳細については、ModuleIDを参照してください。
場合によっては、推移的な依存関係をすべての依存関係から除外する必要があります。これは、excludeDependenciesでExclusionRulesを設定することで実現できます。
excludeDependencies ++= Seq(
// commons-logging is replaced by jcl-over-slf4j
ExclusionRule("commons-logging", "commons-logging")
)
ソースとAPIドキュメントjarのダウンロードは、通常、IDEプラグインによって処理されます。これらのプラグインは、これらのjarを参照するUpdate-Reportを生成するupdateClassifiersタスクとupdateSbtClassifiersタスクを使用します。
IDEプラグインを使用せずにsbtに依存関係のソースをダウンロードさせるには、依存関係定義にwithSources()を追加します。API jarの場合は、withJavadoc()を追加します。例えば
libraryDependencies +=
"org.apache.felix" % "org.apache.felix.framework" % "1.8.0" withSources() withJavadoc()
これは推移的ではないことに注意してください。その場合は、update*Classifiersタスクを使用してください。
追加属性は、extraメソッドにキーと値のペアを渡すことで指定できます。
追加属性で依存関係を選択するには
libraryDependencies += "org" % "name" % "rev" extra("color" -> "blue")
現在のプロジェクトに追加属性を定義するには
projectID := {
val previous = projectID.value
previous.extra("color" -> "blue", "component" -> "compiler-interface")
}
sbtは、Ivy設定ファイルの設定または依存関係セクションをインラインで直接指定することもサポートしています。これをインラインのScalaの依存関係とリポジトリの宣言と組み合わせることができます。
例えば
ivyXML :=
<dependencies>
<dependency org="javax.mail" name="mail" rev="1.4.2">
<exclude module="activation"/>
</dependency>
</dependencies>
デフォルトでは、sbtは標準のIvyホームディレクトリの場所である${user.home}/.ivy2/を使用します。これは、sbtランチャーとプロジェクトの両方で使用するために、sbt起動スクリプト（セットアップに記載）でシステムプロパティsbt.ivy.homeを設定することで、マシン全体で設定できます。
例えば
java -Dsbt.ivy.home=/tmp/.ivy2/ ...
sbtは（Ivyを介して）デフォルトでダウンロードされたファイルのチェックサムを検証します。また、デフォルトでアーティファクトのチェックサムを公開します。使用するチェックサムは、*checksums*設定で指定します。
更新中のチェックサムチェックを無効にするには
update / checksums := Nil
アーティファクトの公開中のチェックサム作成を無効にするには
publishLocal / checksums := Nil
publish / checksums := Nil
デフォルト値は
checksums := Seq("sha1", "md5")
競合マネージャーは、依存関係の解決によって同じライブラリの異なるバージョンが導入された場合にどうするかを決定します。デフォルトでは、最新のバージョンが選択されます。これは、ConflictManager型のconflictManagerを設定することで変更できます。異なる競合マネージャーの詳細については、Ivyのドキュメントを参照してください。たとえば、競合を許可しないように指定するには、
conflictManager := ConflictManager.strict
これを設定すると、競合が発生した場合にエラーが発生します。競合を解決するには、後のセクションで説明する依存関係のオーバーライドを設定する必要があります。
banana-rdfにはakka-actor 2.1.4が必要なため、次の直接依存関係はakka-actorバージョンで競合を引き起こします。
libraryDependencies ++= Seq(
"org.w3" %% "banana-rdf" % "0.4",
"com.typesafe.akka" %% "akka-actor" % "2.3.7",
)
デフォルトの競合マネージャーは、akka-actorの新しいバージョン2.3.7を選択します。これは、新しいバージョンが選択され、古いバージョンがエビクトされたことを示すshow updateの出力で確認できます。
> show update
[info] compile:
[info] com.typesafe.akka:akka-actor_2.10
[info] - 2.3.7
...
[info] - 2.1.4
...
[info] evicted: true
[info] evictedReason: latest-revision
...
[info] callers: org.w3:banana-rdf_2.10:0.4
さらに、akka-actor 2.1.4と2.3.7のバイナリバージョンの互換性は、2番目のセグメントがバンプアップされているため保証されません。 sbt 0.13.6+はこれを自動的に検出し、次の警告を出力します
[warn] There may be incompatibilities among your library dependencies.
[warn] Here are some of the libraries that were evicted:
[warn] * com.typesafe.akka:akka-actor_2.10:2.1.4 -> 2.3.7
[warn] Run 'evicted' to see detailed eviction warnings
akka-actor 2.1.4と2.3.7はバイナリ互換性がないため、これを修正する唯一の方法は、依存関係をakka-actor 2.1.4にダウングレードするか、banana-rdfをakka-actor 2.3を使用するようにアップグレードすることです。
バイナリ互換性のある競合の場合、sbtは依存関係のオーバーライドを提供します。これらは、ModuleIDのセットであるdependencyOverrides設定で構成されます。たとえば、sparkはlog4j 1.2.16を使用し、scalaxbはlog4j 1.2.17を使用するため、次の依存関係定義は競合します。
libraryDependencies ++= Seq(
"org.spark-project" %% "spark-core" % "0.5.1",
"org.scalaxb" %% "scalaxb" % "1.0.0"
)
デフォルトの競合マネージャーは、log4jの最新リビジョン1.2.17を選択します
> show update
[info] compile:
[info] log4j:log4j:1.2.17: ...
...
[info] (EVICTED) log4j:log4j:1.2.16
...
選択されたバージョンを変更するには、オーバーライドを追加します
dependencyOverrides += "log4j" % "log4j" % "1.2.16"
これにより、log4jへの直接の依存関係は追加されませんが、リビジョンは1.2.16に強制されます。これは、show updateの出力によって確認されます
> show update
[info] compile:
[info] log4j:log4j:1.2.16
...
**注：**これはIvyのみの機能であり、公開されたpom.xmlには含まれません。
プロジェクトに次の依存関係を追加すると、vpp 2.2.1の未解決の依存関係エラーが発生します
libraryDependencies += "org.apache.cayenne.plugins" % "maven-cayenne-plugin" % "3.0.2"
sbt 0.13.6+は、管理対象の依存関係の解決に失敗した場合、依存関係ツリーの再構築を試みます。これは近似値ですが、問題のある依存関係の出所を特定するのに役立ちます。可能な場合は、sbtはモジュールの横にソースの位置を表示します
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] :: UNRESOLVED DEPENDENCIES ::
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] :: foundrylogic.vpp#vpp;2.2.1: not found
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn]
[warn] Note: Unresolved dependencies path:
[warn] foundrylogic.vpp:vpp:2.2.1
[warn] +- org.apache.cayenne:cayenne-tools:3.0.2
[warn] +- org.apache.cayenne.plugins:maven-cayenne-plugin:3.0.2 (/foo/some-test/build.sbt#L28)
[warn] +- d:d_2.10:0.1-SNAPSHOT
パフォーマンスの向上オプションについては、キャッシュされた解決を参照してください。
プロジェクトの公開方法については、公開を参照してください。
Ivyの設定は、プラグインなどのカスタムの依存関係グループが必要な場合に、ビルドにとって便利な機能です。 Ivyの設定は、本質的に依存関係の名前付きセットです。詳細については、Ivyのドキュメントを参照してください。
sbtでの設定の組み込み使用法は、Mavenのスコープに似ています。 sbtは、定義されている設定によって、異なるクラスパスに依存関係を追加します。詳細については、Mavenスコープの説明を参照してください。
1つ以上の設定を選択して、プロジェクトの1つ以上の設定にマップすることにより、依存関係を設定に配置します。最も一般的なケースは、設定の1つであるAが依存関係の設定Bを使用することです。このマッピングは、"A->B"のようになります。このマッピングを依存関係に適用するには、依存関係定義の最後に追加します
libraryDependencies += "org.scalatest" %% "scalatest" % "3.2.17" % "test->compile"
これは、プロジェクトの"test"設定がScalaTestの"compile"設定を使用していることを示しています。より高度なマッピングについては、Ivyのドキュメントを参照してください。 Mavenリポジトリに公開されているほとんどのプロジェクトは、"compile"設定を使用します。
設定の便利なアプリケーションは、通常のクラスパスで使用されない依存関係をグループ化することです。たとえば、プロジェクトは"js"設定を使用してjQueryを自動的にダウンロードし、resourcesを変更することでjarに含めることができます。例えば
val JS = config("js") hide
ivyConfigurations += JS
libraryDependencies += "jquery" % "jquery" % "3.2.1" % "js->default" from "https://code.jquery.com/jquery-3.2.1.min.js"
Compile / resources ++= update.value.select(configurationFilter("js"))
configメソッドは、"js"という名前の新しい設定を定義し、公開に使用されないようにプロジェクトに対してプライベートにします。管理対象アーティファクトの選択の詳細については、更新レポートを参照してください。
マッピングのない設定（"->"なし）は、"default"または"compile"にマップされます。 ->は、これらとは異なる設定にマッピングする場合にのみ必要です。上記のScalaTestの依存関係は、次のように短縮できます。
libraryDependencies += "org.scalatest" %% "scalatest" % "3.2.17" % "test"
**注**：強制すると論理的な矛盾が生じる可能性があるため、推奨されなくなりました。
間接的な依存関係のバージョンよりも指定したバージョンを優先するには、force()を使用します
libraryDependencies ++= Seq(
"org.spark-project" %% "spark-core" % "0.5.1",
"log4j" % "log4j" % "1.2.14" force()
)
**注：**これはIvyのみの機能であり、公開されたpom.xmlに含めることはできません。
Mavenのサポートは、CoursierまたはIvyのMaven POMのサポートに依存しています。このサポートに関する既知の問題
parentセクションでrelativePathを指定すると、エラーが発生します。ivysettings.xmlファイルで指定することです。
