)

NomoLog

Log of my life and program

SBT Libraries and Plugins

Posted in Scala Tagged as SBT

ある日のぼく

ぼくはSBTのプラグインを入れようとしていました。

ぼく「sbteclipse-plugin入れたいなあ^^ なになに、project/plugins.sbt

1
2
3
resolvers += Classpaths.typesafeResolver

addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.4.0"

って書けばいいのかなるほど!」

ぼく「でも"com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.4.0"ってproject/Build.scalaLibraryDependenciesと同じ書式だけどこっちに書いちゃダメなのかなあ。書いてみよう!」←動かず

ぼく「てかそもそもproject/plugins.sbtとかproject/Build.scalaとかBuild.sbtとかなんなんだっけ?どういう関係だっけ?調べてみよう!」

ここに全て書いてあるけど自分なりにまとめたよ!

SBTのビルド定義やらライブラリの依存性やら何度勉強しても忘れるのでここで一発まとめちゃおうと思います!!

今回は以下のディレクトリ構造を想定します。

1
2
3
4
5
6
hello/
 build.sbt

 project/
  Build.scala
  plugins.sbt

ライブラリ?プラグイン?

そもそも今回の問題は自分の中でライブラリとプラグインの定義が曖昧だったことが始まりでした。SBTで言うところのプラグインの追加とは、

ビルド定義にライブラリ依存性を追加することを意味する。

らしいです。

SBTではプロジェクト(上記のhelloとします)のビルド定義はbuild.sbtproject/Build.scalaに記述します。各ファイルにプロジェクト名やScalaのバージョンやビルドスルために必要なライブラリを書いてあげることをビルド定義と呼ぶわけです。

そしてプラグインとはこのビルド定義の拡張に他なりません。他ならないそうです。

ですので、このビルド定義に対してまたビルド定義してあげることがプラグインの追加になるそうです。

SBTの再帰構造

SBTではビルド定義自体をまたプロジェクトとして扱うことができます。つまり、

1
2
3
4
5
6
7
8
9
10
11
12
13
hello/
 build.sbt

 project/
  Build.scala
  plugins.sbt
  project/
   Build.scala
   plugins.sbt   
   project/
    Build.scala
    plugins.sbt   
      ...

な感じでビルド定義のビルド定義のビルド定義の…みたいなことができちゃうわけです。

ようはbuild.sbtplugins.sbtは役割的には同じなわけです。ただ、対象とするプロジェクトが異なりますということです。

まとめ

書いてたら眠くなったのでこの辺にしときます!

SBTプロジェクト内のファイル関係はこれである程度頭に入ったはず!!

Comments