ビルドの構成 

このページでは、ビルド構造の構成について説明します。

最初に「はじめに」ガイドの前のページを読んでください。特に、このページを読む前に、build.sbt、タスクグラフ、ライブラリの依存関係、および マルチプロジェクトビルド を理解する必要があります。

sbt は再帰的です 

build.sbt は、sbt が実際にどのように動作するかを隠しています。 sbt ビルドは Scala コードで定義されています。そのコード自体をビルドする必要があります。 sbt を使用する方法が最適です。

project ディレクトリは、_ビルド内の別のビルド_であり、ビルドのビルド方法を知っています。ビルドを区別するために、ビルドを指す場合は**適切なビルド**という用語を使用し、project 内のビルドを指す場合は**メタビルド**という用語を使用することがあります。メタビルド内のプロジェクトは、他のプロジェクトができることなら何でもできます。 _ビルド定義は sbt プロジェクトです。_

そして、タートルはひたすら続きます。必要に応じて、project/project/ ディレクトリを作成することで、ビルド定義プロジェクトのビルド定義を調整できます。

図を以下に示します。

hello/                     # your build's root project's base directory

    Hello.scala            # a source file in your build's root project
                           #   (could be in src/main/scala too)

    build.sbt              # build.sbt is part of the source code for
                           #   meta-build's root project inside project/;
                           #   the build definition for your build

    project/               # base directory of meta-build's root project

        Dependencies.scala # a source file in the meta-build's root project,
                           #   that is, a source file in the build definition
                           #   the build definition for your build

        assembly.sbt       # this is part of the source code for
                           #   meta-meta-build's root project in project/project;
                           #   build definition's build definition

        project/           # base directory of meta-meta-build's root project;
                           #   the build definition project for the build definition

            MetaDeps.scala # source file in the root project of
                           #   meta-meta-build in project/project/

_心配しないでください！_ほとんどの場合、すべてが必要になるわけではありません。しかし、原則を理解することは役に立ちます。

ちなみに: .scala または .sbt で終わるファイルが使用される場合、それらを build.sbt および Dependencies.scala と命名することは単なる規則です。これは、複数のファイルが許可されていることも意味します。

依存関係を一箇所で追跡する 

project の下の .scala ファイルがビルド定義の一部になるという事実を使用する 1 つの方法は、依存関係を一箇所で追跡するために project/Dependencies.scala を作成することです。

import sbt._

object Dependencies {
  // Versions
  lazy val akkaVersion = "2.6.21"

  // Libraries
  val akkaActor = "com.typesafe.akka" %% "akka-actor" % akkaVersion
  val akkaCluster = "com.typesafe.akka" %% "akka-cluster" % akkaVersion
  val specs2core = "org.specs2" %% "specs2-core" % "4.20.0"

  // Projects
  val backendDeps =
    Seq(akkaActor, specs2core % Test)
}

Dependencies オブジェクトは build.sbt で使用できます。定義されている val を使いやすくするために、build.sbt ファイルに Dependencies._ をインポートします。

import Dependencies._

ThisBuild / organization := "com.example"
ThisBuild / version      := "0.1.0-SNAPSHOT"
ThisBuild / scalaVersion := "2.12.18"

lazy val backend = (project in file("backend"))
  .settings(
    name := "backend",
    libraryDependencies ++= backendDeps
  )

この手法は、大規模になっているマルチプロジェクトビルドがあり、サブプロジェクトに一貫性のある依存関係があることを確認する場合に役立ちます。

.scala ファイルを使用する場合 

.scala ファイルでは、トップレベルのクラスやオブジェクトを含む、任意の Scala コードを記述できます。

推奨されるアプローチは、マルチプロジェクト build.sbt ファイルでほとんどの設定を定義し、タスクの実装やキーなどの値を共有するために project/*.scala ファイルを使用することです。 .scala ファイルの使用は、あなたまたはあなたのチームが Scala にどの程度精通しているかにも依存します。

自動プラグインの定義 

上級ユーザー向けに、ビルドを編成する別の方法は、project/*.scala にワンオフの 自動プラグイン を定義することです。トリガーされたプラグインを定義することにより、自動プラグインはすべてのサブプロジェクトにカスタムタスクとコマンドを挿入する便利な方法として使用できます。