マルチプロジェクト

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 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.

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.

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.

You cannot have a project subdirectory or project/*.scala files in the sub-projects. foo/project/Build.scala would be ignored. Aggregation

Projects in the build can be completely independent of one another, if you want.

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.

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.

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:

aggregate in update := false

aggregate in update is the aggregate key scoped to the update task, see scopes.

Note: aggregation will run the aggregated tasks in parallel and with no defined ordering. Classpath dependencies

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:

  lazy val foo = Project(id = "hello-foo",
                         base = file("foo")) dependsOn(bar)

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.

To depend on multiple projects, use multiple arguments to dependsOn, like dependsOn(bar, baz). Per-configuration classpath dependencies

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").

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.

次はカスタム設定とタスク