sbt Reference Manual

sbt Reference Manual 読んだ



  • project level task:
    • clean, publish, publishLocal, update
  • configuration level task:
    • compile, console, consoleQuick...

inspectでTaskかSettingか分かる inspect actual <key>

incremental compiler の詳細表示

set incOptions := incOptions.value.copy(apiDebug = true)

testOnly org.example.MyTest -- -verbosity 1 testOptionsへ直接値を渡す

testOptions in Test += Tests.Setup( () => println("Setup") )
testOptions in Test += Tests.Cleanup( () => println("Cleanup") )
testOptions in Test += Tests.Setup( loader => ... )
testOptions in Test += Tests.Cleanup( loader => ... )
Custom Test Framework

(success表示するようにして、or 何か適当なの出して、last-grepでsuccess探せばいける?)
Avoid fetching artifact dependencies with either intransitive() or notTransitive(), as in this example:

libraryDependencies += "org.apache.felix" % "org.apache.felix.framework" % "1.8.0" intransitive()

Ivy Home Directory
java -Dsbt.ivy.home=/tmp/.ivy2/ ...

checksums := Seq("sha1", "md5")
Proxy repositories provide a single point of remote download for an organization. In addition to control and security concerns, Proxy repositories are primarily important for increased speed across a team.

Tasks and Commands

Both settings and tasks produce values, but there are two major differences between them:

  • Settings are evaluated at project load time. Tasks are executed on demand, often in response to a command from the user.
  • At the beginning of project loading, settings and their dependencies are fixed. Tasks can introduce new tasks during execution, however.

The name of the val is used when referring to the task in Scala code and at the command line. The string passed to the taskKey method is a description of the task

Implement the task

There are three main parts to implementing a task once its key is defined:

  • Determine the settings and other tasks needed by the task. They are the task’s inputs.
  • Define the code that implements the task in terms of these inputs.
  • Determine the scope the task will go in.


lazy val hello = taskKey[Unit]("Prints 'Hello World'")

hello := println("hello world!")
Separating implementations

The implementation of a task can be separated from the binding. For example, a basic separate definition looks like:

// Define a new, standalone task implemention
lazy val intTaskImpl: Initialize[Task[Int]] =
Def.task { sampleTask.value - 3 }
// Bind the implementation to a specific key
intTask := intTaskImpl.value

The all method applies to both settings (values of type Initialize[T]) and tasks (values of type Initialize[Task[T]]).

Some scopes might not define a setting or task. The ? and ?? methods can help in this case. 後でもっかい タスクの成功/失敗の例とかここにある
Call .parsed on an InputTask[T] or Initialize[InputTask[T]] to get the Task[T] created after parsing the command line
Call .evaluated on an InputTask[T] or Initialize[InputTask[T]] to get the value of type T from evaluating that task

run: Initialize[Task[ScalaRun]]
runMain: Initialize[InputTask[Unit]]

import grizzled.sys._
import OperatingSystem._
libraryDependencies ++=
    if(os == Windows)
sbt plugin書く人のbest practices

  • 作ったら知らせてね
  • デフォルトパッケージは使わない
  • SettingやTaskを使ってCommandを避ける
    • Tasks can take advantage of duplication reduction and parallel execution by the task engine
    • Settings can be composed from other settings and tasks. Tasks can be composed from other tasks and input tasks. Commands, on the other hand, cannot be composed from any of the above.
  • AutoPlugin使う
  • 既存のキーは再利用する
  • 中心となる機能を単純なプロジェクトに入れてみる
  • 独自の設定(configuration)を使うのを避けて、既存のものを利用する
    • 別のスコープになるようなものが使えるなら、それでもいいよ


sbt.boot.propertieの[app]のとこにxMain起動するって書いてる ← この辺前にsbtのソース読んだとこに書いたな

After loading/compiling all the build definitions, sbt has a series of Seq[Setting[_]] that it must order. As shown in the diagram, the default inclusion order for sbt is:

All AutoPlugin settings
All settings defined in project/Build.scala
All settings defined in the user directory (~/.sbt/<verison>/*.sbt)
All local configurations (build.sbt)

last compile


// Execute tests in the current project serially
//   Tests from other projects may still run concurrently.
parallelExecution in Test := false

Be aware that compilation and tests run in parallel by default in sbt 0.13.7

良い感じのBuild.scalaの例、紹介されてんじゃん のBuild.scalaもこれ見て書いたのかな

How can a task avoid redoing work if the input files are unchanged?