sbtノート7依存管理
クラスライブラリ依存は、次の2つの方法で追加できます.非管理依存(unmanaged dependencies)はjarファイルをlibディレクトリ に配置する.ホスティング依存(managed dependencies)は、構築定義で構成され、 がリソースウェアハウスから自動的にダウンロードされます.
非管理依存
多くの人は、非管理依存の代わりに管理依存を使用します.しかし、非管理ではより簡単に始めることができます.
非管理依存性は、jarファイルをlibに追加し、プロジェクトのclasspathに配置します.
テストjarパッケージをlibに入れることもできます.例えば、ScalaCheck、specs、ScalaTestなどです.
libでの依存は、すべてのclasspath(compile,test,run、console)に追加されます.どちらかのclasspathを変更したい場合は、調整できます.
dependencyClasspath
in
Compileまたは
dependencyClasspath
in
Runtime.~=を使用して以前のclasspath値を取得し、その一部をフィルタリングし、新しいclasspath値を返すことができます.~=詳細については
more about settings.
非管理依存はbuild.sbtは何でも追加しますが、libではなく別のフォルダを使用したい場合は、unmanaged-baseキーを変更できます.
custom_でlibの代わりにlib:
more about settings.
また、unmanaged-jarsタスクは、unmanaged-baseフォルダのjarファイルをリストするために使用されます.複数のフォルダを使用したり、より複雑なことをしたりする場合は、unmanaged-jarsタスク全体を置き換えて他のことをする必要があります.
管理依存
sbtはApache Ivyを使用して管理依存を実現しているので、MavenやIvyに詳しいなら、あまり面倒ではありません.
The libraryDependencies key
ほとんどの場合、libraryDependencies設定に依存パッケージを簡単にリストできます.Maven POMファイルまたはIvyプロファイルを書いて依存を構成し、sbtにこれらの外部プロファイルを使用させることもできます.
依存を宣言すると、groupId、artifactId、revisionが文字列であるように見えます.
もちろん、sbt(Ivyを通じて)はこれらのモジュールをどこでダウンロードするかを知る必要があります.モジュールがsbtのデフォルトのリソースウェアハウスの1つにある場合、モジュールは動作します.たとえば、Apache Derbyはデフォルトのリソース・ウェアハウスにあります.
もちろん、++=を使用して依存リストを一度に追加することができます.
少ない場合、=,<=,<+=などという理由で使用することもできます.
%を使用して正しいScalaバージョンを取得します(Getting the right Scala version with%%)
groupID%artifactID%revision(groupID%artifactID%revisionではなくgroupID%artifactID%revision)を使用すると、sbtはプロジェクトのScalaバージョンをartifact nameに追加します.これは簡単な例です.%%を使わなくてもいいです.
この実践の複雑さは、通常、依存パッケージが微細に異なるScalaバージョンで動作できることである.しかし%%はあまりスマートではありません.したがって、依存は2.9.0で有効ですが、scalaVersion:="2.9.1"を使用すると、2.9.0依存でも動作する可能性が高い場合でも%%を使用できません.%%が作業を停止した場合は、この依存が実際にどのバージョンのために構築されているかを確認し、それが動作できると思うものをハードコーディングします(このようなものがあると仮定します).
詳細については、Cross-buildingを参照してください.
Ivy revisions
groupID%artifactiID%revisionのrevisionは、一意の固定バージョンでなくてもよい.Ivyは、「1.6.1」などの固定リビジョンの代わりにモジュールの最終リビジョンを選択できます.「latest.integration」、「2.9.+」または「[1.0,)」を指定する必要があります.詳細は、Ivy revisionsドキュメントを参照してください.
Resolvers
すべてのパッケージが同じサーバにあるわけではありません.sbtはデフォルトで標準Maven 2リソースウェアハウスを使用します.依存がデフォルトのリソースウェアハウスにない場合は、Ivyがそれを見つけるのを助けるためにresolverを追加する必要があります.
追加のリソースウェアハウスを追加し、
例:
resolversキーはKeysで次のように定義されます.
sbtは、ローカルのMavenリソースウェアハウスを検索できます(リソースウェアハウスとして追加する場合):
Resolversは、他のリソース・ウェアハウスのタイプを定義する詳細を入手します.
デフォルトresolversの上書き
resolversにはデフォルトのresolversは含まれていません.コンストラクション定義ファイルに追加された追加コンテンツのみです.
sbtはresolversとデフォルトのリソースウェアハウスを組み合わせてexternal-resolversを構成します.
したがって、デフォルトのresolversを変更または削除するには、external-resolvers(resolversの代わりに)を書き換える必要があります.
Per-configuration dependencies
よくあなたのテストコードに依存して使用されます(src/test/scalaでは、Test構成でコンパイルされています).mainコードではありません.
Compile構成ではなくTest構成のclasspathに依存を表示させたい場合は、%「test」を追加します.
ScalaCheck,specs,ScalaTestなどのテスト関連の依存性は%「test」で定義する必要がある.
非管理依存
多くの人は、非管理依存の代わりに管理依存を使用します.しかし、非管理ではより簡単に始めることができます.
非管理依存性は、jarファイルをlibに追加し、プロジェクトのclasspathに配置します.
テストjarパッケージをlibに入れることもできます.例えば、ScalaCheck、specs、ScalaTestなどです.
libでの依存は、すべてのclasspath(compile,test,run、console)に追加されます.どちらかのclasspathを変更したい場合は、調整できます.
dependencyClasspath
in
Compileまたは
dependencyClasspath
in
Runtime.~=を使用して以前のclasspath値を取得し、その一部をフィルタリングし、新しいclasspath値を返すことができます.~=詳細については
more about settings.
非管理依存はbuild.sbtは何でも追加しますが、libではなく別のフォルダを使用したい場合は、unmanaged-baseキーを変更できます.
custom_でlibの代わりにlib:
unmanagedBase <<= baseDirectory { base => base / "custom_lib" }
baseDirectoryはプロジェクトのルートディレクトリです.ここで、修正されたunmanagedBaseはbaseDirectoryに依存し、<=の使い方はmore about settings.
また、unmanaged-jarsタスクは、unmanaged-baseフォルダのjarファイルをリストするために使用されます.複数のフォルダを使用したり、より複雑なことをしたりする場合は、unmanaged-jarsタスク全体を置き換えて他のことをする必要があります.
管理依存
sbtはApache Ivyを使用して管理依存を実現しているので、MavenやIvyに詳しいなら、あまり面倒ではありません.
The libraryDependencies key
ほとんどの場合、libraryDependencies設定に依存パッケージを簡単にリストできます.Maven POMファイルまたはIvyプロファイルを書いて依存を構成し、sbtにこれらの外部プロファイルを使用させることもできます.
依存を宣言すると、groupId、artifactId、revisionが文字列であるように見えます.
libraryDependencies += groupID % artifactID % revision
またはconfigurationも文字列です.libraryDependencies += groupID % artifactID % revision % configuration
libraryDependenciesはKeysで次のように宣言しています.val libraryDependencies = SettingKey[Seq[ModuleID]]("library-dependencies", "Declares managed dependencies.")
%メソッド文字列からModuleIDオブジェクトを作成し、libraryDependenciesにこのModuleIDを追加します.もちろん、sbt(Ivyを通じて)はこれらのモジュールをどこでダウンロードするかを知る必要があります.モジュールがsbtのデフォルトのリソースウェアハウスの1つにある場合、モジュールは動作します.たとえば、Apache Derbyはデフォルトのリソース・ウェアハウスにあります.
libraryDependencies += "org.apache.derby" % "derby" % "10.4.1.3"
もしあなたがbuildにいたら.sbtに入力、update、sbtはDerbyを~/にダウンロードする.ivy2/cache/org.apache.derby/.(ちなみにupdateはcompile依存なので、ほとんどの時間は手動でupdateを入力する必要はありません.)もちろん、++=を使用して依存リストを一度に追加することができます.
libraryDependencies ++= Seq(
groupID % artifactID % revision,
groupID % otherID % otherRevision
)
少ない場合、=,<=,<+=などという理由で使用することもできます.
%を使用して正しいScalaバージョンを取得します(Getting the right Scala version with%%)
groupID%artifactID%revision(groupID%artifactID%revisionではなくgroupID%artifactID%revision)を使用すると、sbtはプロジェクトのScalaバージョンをartifact nameに追加します.これは簡単な例です.%%を使わなくてもいいです.
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"を使用すると、2.9.0依存でも動作する可能性が高い場合でも%%を使用できません.%%が作業を停止した場合は、この依存が実際にどのバージョンのために構築されているかを確認し、それが動作できると思うものをハードコーディングします(このようなものがあると仮定します).
詳細については、Cross-buildingを参照してください.
Ivy revisions
groupID%artifactiID%revisionのrevisionは、一意の固定バージョンでなくてもよい.Ivyは、「1.6.1」などの固定リビジョンの代わりにモジュールの最終リビジョンを選択できます.「latest.integration」、「2.9.+」または「[1.0,)」を指定する必要があります.詳細は、Ivy revisionsドキュメントを参照してください.
Resolvers
すべてのパッケージが同じサーバにあるわけではありません.sbtはデフォルトで標準Maven 2リソースウェアハウスを使用します.依存がデフォルトのリソースウェアハウスにない場合は、Ivyがそれを見つけるのを助けるためにresolverを追加する必要があります.
追加のリソースウェアハウスを追加し、
resolvers += name at location
例:
resolvers += "Sonatype OSS Snapshots" at "https://oss.sonatype.org/content/repositories/snapshots"
resolversキーはKeysで次のように定義されます.
val resolvers = SettingKey[Seq[Resolver]]("resolvers", "The user-defined additional resolvers for automatically managed dependencies.")
atメソッドは、2つの文字列から1つのResolverオブジェクトを作成します.sbtは、ローカルのMavenリソースウェアハウスを検索できます(リソースウェアハウスとして追加する場合):
resolvers += "Local Maven Repository" at "file://"+Path.userHome.absolutePath+"/.m2/repository"
表示Resolversは、他のリソース・ウェアハウスのタイプを定義する詳細を入手します.
デフォルトresolversの上書き
resolversにはデフォルトのresolversは含まれていません.コンストラクション定義ファイルに追加された追加コンテンツのみです.
sbtはresolversとデフォルトのリソースウェアハウスを組み合わせてexternal-resolversを構成します.
したがって、デフォルトのresolversを変更または削除するには、external-resolvers(resolversの代わりに)を書き換える必要があります.
Per-configuration dependencies
よくあなたのテストコードに依存して使用されます(src/test/scalaでは、Test構成でコンパイルされています).mainコードではありません.
Compile構成ではなくTest構成のclasspathに依存を表示させたい場合は、%「test」を追加します.
libraryDependencies += "org.apache.derby" % "derby" % "10.4.1.3" % "test"
現在、sbtインタラクティブプロンプトにshow compile:dependency-classpathを入力するとderbyは表示されません.しかし、show test:dependency-classpathを入力すると、derbyのjarがリストに表示されます.ScalaCheck,specs,ScalaTestなどのテスト関連の依存性は%「test」で定義する必要がある.