| Deletions are marked like this. | Additions are marked like this. |
| Line 63: | Line 63: |
| hello-foo/*:version was defined in hello/foo/build.sbt, hello-bar/*:version was defined in hello/bar/build.sbt, and hello/*:version was defined in hello/build.sbt. Remember the syntax for scoped keys. Each version key is scoped to a project, based on the location of the build.sbt. But all three build.sbt are part of the same build definition. |
hello-foo/*:versionはhello/foo/build.sbt中で定義され、hello-bar/*:versionはhello/bar/build.sbt中で定義され、hello/*:versionはhello/build.sbt中で定義されている。 スコープキーの構文を思い起こそう。 各versionキーはプロジェクトにスコープ付されているのだが、これはbuild.sbtの位置に基づいている。 しかし、これら三つのbuild.sbtは同じ一つのビルド定義の一部なのである。 |
| Line 65: | Line 68: |
| Each project's settings can go in .sbt files in the base directory of that project, while the .scala file can be as simple as the one shown above, listing the projects and base directories. There is no need to put settings in the .scala file. |
各プロジェクトのsettingは、そのプロジェクトのベースディレクトリ中の.sbtファイルに記述される。 その一方で、.scalaファイルは上にしめしたように、可能な限り単純にすることができる。 単に、プロジェクトをリストしてそのベースディレクトリを設定するだけだ。 .scalaファイルにsettingを格納する必要はない。 |
| Line 67: | Line 73: |
| You may find it cleaner to put everything including settings in .scala files in order to keep all build definition under a single project directory, however. It's up to you. | しかし、settingも含めてすべてを.scalaファイルに格納する方がすっきりすると思うかもしれない。それは君におまかせする。 |
| Line 69: | Line 75: |
|
You cannot have a project subdirectory or project/*.scala files in the sub-projects. foo/project/Build.scala would be ignored. Aggregation |
しかし、サブプロジェクトに、projectサブディレクトリ、つまりproject/*.scalaファイルを持たせることはできない。 つまり、foo/project/Build.scalaは無視される。 |
| Line 72: | Line 78: |
| Projects in the build can be completely independent of one another, if you want. | == 集約(aggregate) == |
| Line 74: | Line 80: |
| In the above example, however, you can see the method call aggregate(foo, bar). This aggregates hello-foo and hello-bar underneath the root project. | 望むなら、ビルド中のプロジェクトは完全に他から独立させることもできる。 |
| Line 76: | Line 82: |
| Aggregation means that running a task on the aggregate project will also run it on the aggregated projects. Start up sbt with two subprojects as in the example, and try compile. You should see that all three projects are compiled. |
しかし、上記の例では、aggregate(foo, bar)というメソッド呼び出しが存在するののがわかると思う。 これは、ルートプロジェクトしたにhello-foo,hello-barを集約するということだ。 |
| Line 78: | Line 85: |
| In the project doing the aggregating, the root hello project in this case, you can control aggregation per-task. So for example in hello/build.sbt you could avoid aggregating the update task: |
集約の意味するところとしては、集約プロジェクトについてタスクを実行すると、集約されたプロジェクトについても同じタスクが実行されるということだ。 例えば、サンプルのように二つのサブプロジェクトを持つプロジェクトでsbtを実行し、compileしてみよう。 三つの全プロジェクトがコンパイルされることがわかると思う。 集約を行うプロジェクトにおいて、この場合はhelloプロジェクトだが、 タスクごとの集約をコントロールすることができる。 例えば、hello/build.sbtでupdateタスクを集約しないようにすることができる。 |
| Line 82: | Line 97: |
| aggregate in update is the aggregate key scoped to the update task, see scopes. | 「aggregate in update」はupdateタスクにスコープ付されたaggregateキーだ。「スコープ」を参照のこと。 |
| Line 84: | Line 99: |
|
Note: aggregation will run the aggregated tasks in parallel and with no defined ordering. Classpath dependencies |
注意：集約は集約されたタスクを並列に実行する、定義された順序というものはない。 |
| Line 87: | Line 101: |
| A project may depend on code in another project. This is done by adding a dependsOn method call. For example, if hello-foo needed the classpath from hello-bar, you would write in your Build.scala: |
== クラスパスの依存 == プロジェクトは他のプロジェクトのコードに依存することがある。 これをdependsOnメソッドコールで追加することができる。 例えば、hello-fooがgello-barのクラスパスを必要とするなら、 Build.scalaに以下のように記述することができる。 |
| Line 92: | Line 112: |
| Now code in hello-foo can use classes from hello-bar. This also creates an ordering between the projects when compiling them; hello-bar must be updated and compiled before hello-foo can be compiled. | |
| Line 94: | Line 113: |
|
To depend on multiple projects, use multiple arguments to dependsOn, like dependsOn(bar, baz). Per-configuration classpath dependencies |
これで、hello-fooはhello-barのクラスを使用することができる。 これは同時に、プロジェクトのコンパイル順序を決めることでもある。 hello-barはhello-fooがコンパイルされる前にupdateされていなければならない。 |
| Line 97: | Line 117: |
| foo dependsOn(bar) means that the Compile configuration in foo depends on the Compile configuration in bar. You could write this explicitly as dependsOn(bar % "compile->compile"). |
複数のプロジェクトに依存させたいのであれば、dependsOnに対する複数引数を使う。dependsOn(bar, baz)のように。 == コンフィギュレーション毎クラスパス依存 == 「foo dependsOn(bar)」はfooにおけるCompileコンフィギュレーションがbarのCompileコンフィギュレーションに依存するということだ。これを明示的に「dependsOn(bar % "compile->compile")」と記述することもできる。 |
マルチプロジェクト
https://github.com/harrah/xsbt/wiki/Getting-Started-Multi-Projectの訳(2011/10/30時点)
ここでは、一つのビルドで複数のプロジェクトを扱う方法を紹介する。
これまでのページを読んでおいて欲しい。特にこのページの前にbuild.sbtと.scalaビルド定義の知識が必要だ。
マルチプロジェクト
一つのビルドの中に、互いに関連する複数のプロジェクトを格納できれば便利だろう。 特に、それらが依存しあっており、しばしば同時に変更することがあるなら。
各サブプロジェクトは、それ自身のsrc/main/scalaを持ち、packageコマンドを実行すると、それ自身のjarファイルを生成し、 一般に他のプロジェクトと同様に機能する（訳注：？）
.scala中でのプロジェクト定義
複数のプロジェクトを扱うには、まず各プロジェクトを宣言し、それらがどのように関連するかを.scalaファイルに記述しなければならない。 .sbtファイルではこれはできないのだが、ただし各プロジェクトのsettingについては.sbtファイルに記述することができる。 以下に.scalaファイルの例をあげるが、ここでは、helloというルートプロジェクトがあり、これは二つのサブプロジェクトhello-fooとhello-barを集約している。
import sbt._
import Keys._
object HelloBuild extends Build {
lazy val root = Project(id = "hello",
base = file(".")) aggregate(foo, bar)
lazy val foo = Project(id = "hello-foo",
base = file("foo"))
lazy val bar = Project(id = "hello-bar",
base = file("bar"))
}sbtはリフレクションを使ってProjectタイプのフィールドを探し、Projectのリストを作成する。
hello-fooはbase = file("foo")として定義されているので、fooというサブディレクトリに含まれる。 そのソースはfooの直下にあってもよい、例えばfoo/Foo.scalaでもよいし、foo/src/main/scalaにあってもよい 通常のsbtディレクトリ構造がfoo以下に適用される。ただし、ビルド定義ファイルは除く。
fooにある.sbtファイル、例えばfoo/build.sbtは全体ビルド定義にマージされる。ただし、スコープはhello-fooプロジェクトになる。
もし君の全プロジェクトがhello以下にあるなら、 hello/build.sbt, hello/foo/build.sbt, and hello/bar/build.sbtで別のバージョン(version := "0.6"など) を指定してみよう。 そして、sbt対話モードで「show version」とする。 こんな風に表示されるだろう。
> show version [info] hello-foo/*:version [info] 0.7 [info] hello-bar/*:version [info] 0.9 [info] hello/*:version [info] 0.5
hello-foo/*:versionはhello/foo/build.sbt中で定義され、hello-bar/*:versionはhello/bar/build.sbt中で定義され、hello/*:versionはhello/build.sbt中で定義されている。 スコープキーの構文を思い起こそう。 各versionキーはプロジェクトにスコープ付されているのだが、これはbuild.sbtの位置に基づいている。 しかし、これら三つのbuild.sbtは同じ一つのビルド定義の一部なのである。
各プロジェクトのsettingは、そのプロジェクトのベースディレクトリ中の.sbtファイルに記述される。 その一方で、.scalaファイルは上にしめしたように、可能な限り単純にすることができる。 単に、プロジェクトをリストしてそのベースディレクトリを設定するだけだ。 .scalaファイルにsettingを格納する必要はない。
しかし、settingも含めてすべてを.scalaファイルに格納する方がすっきりすると思うかもしれない。それは君におまかせする。
しかし、サブプロジェクトに、projectサブディレクトリ、つまりproject/*.scalaファイルを持たせることはできない。 つまり、foo/project/Build.scalaは無視される。
集約(aggregate)
望むなら、ビルド中のプロジェクトは完全に他から独立させることもできる。
しかし、上記の例では、aggregate(foo, bar)というメソッド呼び出しが存在するののがわかると思う。 これは、ルートプロジェクトしたにhello-foo,hello-barを集約するということだ。
集約の意味するところとしては、集約プロジェクトについてタスクを実行すると、集約されたプロジェクトについても同じタスクが実行されるということだ。 例えば、サンプルのように二つのサブプロジェクトを持つプロジェクトでsbtを実行し、compileしてみよう。 三つの全プロジェクトがコンパイルされることがわかると思う。
集約を行うプロジェクトにおいて、この場合はhelloプロジェクトだが、 タスクごとの集約をコントロールすることができる。 例えば、hello/build.sbtでupdateタスクを集約しないようにすることができる。
aggregate in update := false
「aggregate in update」はupdateタスクにスコープ付されたaggregateキーだ。「スコープ」を参照のこと。
注意：集約は集約されたタスクを並列に実行する、定義された順序というものはない。
クラスパスの依存
プロジェクトは他のプロジェクトのコードに依存することがある。 これをdependsOnメソッドコールで追加することができる。 例えば、hello-fooがgello-barのクラスパスを必要とするなら、 Build.scalaに以下のように記述することができる。
lazy val foo = Project(id = "hello-foo",
base = file("foo")) dependsOn(bar)これで、hello-fooはhello-barのクラスを使用することができる。 これは同時に、プロジェクトのコンパイル順序を決めることでもある。 hello-barはhello-fooがコンパイルされる前にupdateされていなければならない。
複数のプロジェクトに依存させたいのであれば、dependsOnに対する複数引数を使う。dependsOn(bar, baz)のように。
コンフィギュレーション毎クラスパス依存
「foo dependsOn(bar)」はfooにおけるCompileコンフィギュレーションがbarのCompileコンフィギュレーションに依存するということだ。これを明示的に「dependsOn(bar % "compile->compile")」と記述することもできる。
The -> in "compile->compile" means "depends on" so "test->compile" means the Test configuration in foo would depend on the Compile configuration in bar.
Omitting the ->config part implies ->compile, so dependsOn(bar % "test") means that the Test configuration in foo depends on the Compile configuration in bar.
A useful declaration is "test->test" which means Test depends on Test. This allows you to put utility code for testing in bar/src/test/scala and then use that code in foo/src/test/scala, for example.
You can have multiple configurations for a dependency, separated by semicolons. For example, dependsOn(bar % "test->test;compile->compile"). Navigating projects interactively
At the sbt interactive prompt, type projects to list your projects and project <projectname> to select a current project. When you run a task like compile, it runs on the current project. So you don't necessarily have to compile the root project, you could compile only a subproject.