一个简单的build.sbt文件内容以下：html
name := "hello" // 项目名称 organization := "xxx.xxx.xxx" // 组织名称 version := "0.0.1-SNAPSHOT" // 版本号 scalaVersion := "2.9.2" // 使用的Scala版本号 // 其它build定义
其中， name和version的定义是必须的，由于若是想生成jar包的话，这两个属性的值将做为jar包名称的一部分。java
build.sbt的内容其实很好理解，能够简单理解为一行表明一个键值对(Key-Value Pair)，各行之间以空行相分割。git
固然，实际状况要比这复杂，须要理解SBT的Settings引擎才能够彻底领会， 以上原则只是为了便于读者理解build.sbt的内容。github
除了定义以上项目相关信息，咱们还能够在build.sbt中添加项目依赖web
// 添加源代码编译或者运行期间使用的依赖 libraryDependencies += "ch.qos.logback" % "logback-core" % "1.0.0" libraryDependencies += "ch.qos.logback" % "logback-classic" % "1.0.0" // 或者 libraryDependencies ++= Seq( "ch.qos.logback" % "logback-core" % "1.0.0", "ch.qos.logback" % "logback-classic" % "1.0.0", ... ) // 添加测试代码编译或者运行期间使用的依赖 libraryDependencies ++= Seq("org.scalatest" %% "scalatest" % "1.8" % "test")
甚至于直接使用ivy的xml定义格式:shell
ivyXML := <dependencies> <dependency org="org.eclipse.jetty.orbit" name="javax.servlet" rev="3.0.0.v201112011016"> <artifact name="javax.servlet" type="orbit" ext="jar"/> </dependency> <exclude module="junit"/> <exclude module="activation"/> <exclude module="jmxri"/> <exclude module="jmxtools"/> <exclude module="jms"/> <exclude module="mail"/> </dependencies>
在这里，咱们排除了某些没必要要的依赖，而且声明了某个定制过的依赖声明。apache
固然， build.sbt文件中还能够定义不少东西，好比添加插件，声明额外的repository，声明各类编译参数等等，咱们这里就不在一一赘述了。缓存
project目录下的几个文件实际上都是非必须存在的，能够根据状况添加。架构
build.properties 文件声明使用的要使用哪一个版本的SBT来编译当前项目， 最新的sbt boot launcher能够可以兼容编译全部0.10.x版本的SBT构建项目，好比若是我使用的是0.12版本的sbt，但却想用0.11.3版本的sbt来编译当前项目，则能够在build.properties文件中添加 sbt.version=0.11.3 来指定。 默认状况下，当前项目的构建采用使用的sbt boot launcher对应的版本。并发
plugins.sbt 文件用来声明当前项目但愿使用哪些插件来加强当前项目使用的sbt的功能，好比像assembly功能，清理ivy local cache功能，都有相应的sbt插件供使用， 要使用这些插件只须要在plugins.sbt中声明便可，不用本身去再造轮子：
resolvers += Resolver.url("git://github.com/jrudolph/sbt-dependency-graph.git") resolvers += "sbt-idea-repo" at "http://mpeltonen.github.com/maven/" addSbtPlugin("com.github.mpeltonen" % "sbt-idea" % "1.1.0") addSbtPlugin("net.virtual-void" % "sbt-dependency-graph" % "0.6.0")
在笔者的项目中， 使用sbt-idea来生成IDEA IDE对应的meta目录和文件，以便可以使用IDEA来编写项目代码； 使用sbt-dependency-graph来发现项目使用的各个依赖之间的关系；
为了可以成功加载这些sbt插件，咱们将他们的查找位置添加到resolovers当中。有关resolvers的内容，咱们后面将会详细介绍，这里注意一个比较有趣的地方就是，sbt支持直接将相应的github项目做为依赖或者插件依赖，而不用非得先将相应的依赖或者插件发布到maven或者ivy的repository当中才可使用。
以上目录和文件一般是在建立项目的时候须要咱们建立的，实际上， SBT还会在编译或者运行期间自动生成某些相应的目录和文件，好比SBT会在项目的根目录下和project目录下自动生成相应的target目录，并将编译结果或者某些缓存的信息置于其中， 通常状况下，咱们不但愿将这些目录和文件记录到版本控制系统中，因此，一般会将这些目录和文件排除在版本管理以外。
好比， 若是咱们使用git来作版本控制，那么就能够在.gitignore中添加一行 "target/" 来排除项目根目录下和project目录下的target目录及其相关文件。
sbt的managed dependencies采用Apache Ivy的依赖管理方式， 能够支持从Maven或者Ivy的Repository中自动下载相应的依赖。
简单来讲，在SBT中， 使用managed dependencies基本上就意味着往__libraryDependencies__这个Key中添加所须要的依赖， 添加的通常格式以下:
libraryDependencies += groupID % artifactID % revision
好比：
libraryDependencies += "org.apache.derby" % "derby" % "10.4.1.3"
这种格式实际上是简化的常见形式，实际上，咱们还能够作更多微调， 好比：
(1) libraryDependencies += "org.apache.derby" % "derby" % "10.4.1.3" % "test" (2) libraryDependencies += "org.apache.derby" % "derby" % "10.4.1.3" exclude("org", "artifact") (3) libraryDependencies += "org.apache.derby" %% "derby" % "10.4.1.3"
(1)的形式容许咱们限定依赖的范围只限于测试期间； (2)的形势容许咱们排除递归依赖中某些咱们须要排除的依赖； (3)的形式则会在依赖查找的时候，将当前项目使用的scala版本号追加到artifactId以后做为完整的artifactId来查找依赖，好比若是咱们的项目使用scala2.9.2，那么(3)的依赖声明实际上等同于 "org.apache.derby" %% "derby_2.9.2" % "10.4.1.3" ，这种方式更可能是为了简化同一依赖类库存在有多个Scala版本对应的发布的状况。
若是有一堆依赖要添加，一行一行的添加是一种方式，其实也能够一次添加多个依赖：
libraryDependencies ++= Seq("org.apache.derby" %% "derby" % "10.4.1.3", "org.scala-tools" %% "scala-stm" % "0.3", ...)
对于managed dependencies来讲，虽然咱们指定了依赖哪些类库，但有没有想过，SBT是如何知道到哪里去抓取这些类库和相关资料那？！
实际上，默认状况下， SBT回去默认的Maven2的Repository中抓取依赖，但若是默认的Repository中找不到咱们的依赖，那咱们能够经过resolver机制，追加更多的repository让SBT去查找并抓取， 好比：
resolvers += "Sonatype OSS Snapshots" at " https://oss.sonatype.org/content/repositories/snapshots "
at^[at其实是String类型进行了隐式类型转换(Implicit conversion)后目标类型的方法名]以前是要追加的repository的标志名称（任意取），at后面则是要追加的repository的路径。
除了可远程访问的Maven Repo，咱们也能够将本地的Maven Repo追加到resolver的搜索范围：
resolvers += "Local Maven Repository" at "file://"+Path.userHome.absolutePath+"/.m2/repository"
对于简单的项目来说，.sbt形式的build定义文件就能够知足须要了，但若是咱们想要使用SBT的一些高级特性，好比自定义Task， 多模块的项目构建， 就必须使用.scala形式的build定义了。 简单来说，.sbt能干的事情，.scala形式的build定义都能干，反之，则否则。
要使用.scala形式的build定义，只要在当前项目根目录下的project/子目录下新建一个.scala后缀名的scala源代码文件便可，好比Build.scala（名称能够任意，通常使用Build.scala）：
import sbt._ import Keys._ object HelloBuild extends Build { override lazy val settings = super.settings ++ Seq(..) lazy val root = Project(id = "hello", base = file("."), settings = Project.defaultSettings ++ Seq(..)) }
build的定义只要扩展sbt.Build，而后添加相应的逻辑便可，全部代码都是标准的scala代码，在Build定义中，咱们能够添加更多的settings， 添加自定义的task，添加相应的val和方法定义等等， 更多代码实例能够参考SBT Wiki( https://github.com/harrah/xsbt/wiki/Examples )，另外，咱们在后面介绍SBT的更多高级特性的时候，也会引入更多.scala形式的build定义的使用。
NOTE .sbt和.scala之间不得不说的那些事儿 实际上， 两种形式并不排斥，并非说我使用了前者，就不能使用后者，对于某些单一的项目来讲，咱们能够在.sbt中定义经常使用的settings，而在.scala中定义自定义的其它内容， SBT在编译期间，会将.sbt中的settings等定义与.scala中的定义合并，做为最终的build定义使用。 只有在多模块项目构建中，为了不多个.sbt的存在引入过多的繁琐，才会只用.scala形式的build定义。 .sbt和.scala两者之间的settings是可互相访问的， .scala中的内容会被import到.sbt中，而.sbt中的settings也会被添加到.scala的settings当中。默认状况下，.sbt中的settings会被归入Project级别的Scope中，除非明确指定哪些Settings定义的Scope； .scala中则能够将settings归入Build级别的Scope，也能够归入Project级别的Scope。
在了解了.sbt和.scala两种形式的build定义形式以后， 咱们就能够来看看SBT项目构建结构的本质了。
首先， 一个SBT项目，与构建相关联的基本设施能够概况为3个部分， 即：
也就是说， 对于一个SBT项目来讲，SBT在构建的时候，只关心两点：
在以上基础规则的约束下，咱们来引入一个推导条件， 即：
项目的根目录下的project/目录，其自己也是一个标准的SBT项目。
在这个条件下，咱们再来仔细分析hello/project/目录，看它目录下的各项artifacts到底本质上应该是什么。
咱们说项目根目录下的project/子目录下的*.scala文件是当前项目的build定义文件， 而根据以上的推导条件， project/目录自己又是一个SBT项目，咱们还知道，SBT下面下的*.scala都是当前项目的源代码，因此project/下的*.scala文件， 其实都是project这个目录下的SBT项目的源代码，而这些源代码中，若是有人定义了sbt.Build，那么就会被用做project目录上层目录界定的SBT项目的build定义文件， right？！
那么，来想一个问题，若是project/目录下的*.scala是源代码文件，而project目录总体又是一个标准的SBT项目， 假如咱们这些*.scala源码文件中须要依赖其余三方库，一般咱们会怎么作？
对， 在当前项目的根目录下新建一个build.sbt文件，将依赖添加进去，因此，咱们就有了以下的项目结构：
hello/
*.scala
build.sbt
project/
*.scala
build.sbt
也就是说，咱们能够在书写当前项目的build定义的时候(由于build定义也是用scala来写)，借用第三方依赖来完成某些工做，而不用什么都从新去写，在project/build.sbt下添加项目依赖，那么就能够在project/*.scala里面使用，进而构建出hello/项目的build定义是什么， 即hello/project/这个SBT项目，支撑了上一层hello/这个项目的构建！
如今再来想一下，若是hello/project/这个项目的构建要用到其它SBT特性，好比自定义task或者command啥的，咱们该怎么办？！
既然hello/project/也是一个SBT项目，那么按照惯例，咱们就能够再其下再新建一个project/目录，在这个下一层的project/目录下再添加*.scala源文件做为hello/project/这个SBT项目的build定义文件， 整个项目又变成了：
hello/
*.scala
build.sbt
project/
*.scala
build.sbt
/project
*.scala
而若是hello/project/project/下的源码又要依赖其余三方库那？！ God， 再添加*.sbt或更深一层的project/*.scala！
也就是说， 从第一层的项目根目录开始， 其下project/目录内部再嵌套project/目录，能够无限递归，并且每一层的project/目录都界定了一个SBT项目，而每个下层的project目录界定的SBT项目其实都是对上一层的SBT项目作支持，做为上一层SBT项目的build定义项目，这就跟俄罗斯娃娃这种玩具似的， 递归嵌套，一层又包一层：
通常状况下，咱们不会搞这么多嵌套，但理解了SBT项目的这个结构上的本质，能够帮助咱们更好的理解后面的内容，若是读者看一遍没能理解，那不妨多看几回，多参考其余资料，多揣摩揣摩吧！
大部分状况下，咱们都是使用SBT内建的Task，好比compile， run等，实际上， 除了这些，咱们还能够在build定义中添加更多自定义的Task。
自定义SBT的Task其实很简单，就跟把大象关冰箱里同样简单， 概况来讲其实就是:
Task的定义分两部分，第一部分就是要定义一个TaskKey来标志Task， 第二部分则是定义Task的执行逻辑。
假设咱们要定义一个简单的打印"hello, sbt~"信息的task，那第一步就是先定义它的Key，以下代码所示：
val hello = TaskKey[Unit]("hello", "just say hello")
TaskKey的类型指定了对应task的执行结果，由于咱们只想打印一个字符串，不须要返回什么数据，因此定义的是TaskKey[Unit]。 定义TaskKey最主要的一点就是要指定一个名称（好比第一个参数“hello”），这个名称将是咱们调用该task的标志性建筑。 另外，还能够可选择的经过第二个参数传入该task的相应描述和说明。
有了task对应的Key以后，咱们就要定义task对应的执行逻辑，并经过 := 方法将相应的key和执行逻辑定义关联到一块儿：
hello := { println("hello, sbt~") }
完整的task定义代码以下所示：
val hello = TaskKey[Unit]("hello", "just say hello") hello := { println("hello, sbt~") }
NOTE
:= 只是简单的将task的执行逻辑和key关联到一块儿， 若是以前已经将某一执行逻辑跟同一key关联过，则后者将覆盖前者，另外，若是咱们想要服用其余的task的执行逻辑，或者依赖其余task，只有一个:=就有些力不从心了。这些状况下，能够考虑使用~=或者<<=等方法，他们能够借助以前的task来映射或者转换新的task定义。好比（摘自sbt wiki）:
// These two settings are equivalent
intTask <<= intTask map { (value: Int) => value + 1 }
intTask ~= { (value: Int) => value + 1 }
光完成了task的Key和执行逻辑定义还不够，咱们要将这个task添加到项目的Settings当中才能使用它，因此，咱们稍微对以前的代码作一补充：
object ProjectBuild extends Build { val hello = TaskKey[Unit]("hello", "just say hello") val helloTaskSetting = hello := { println("hello, sbt~") } lazy val root = Project(id = "", base = file(".")).settings(Defaults.defaultSettings ++ Seq(helloTaskSetting): _*) }
将Key与task的执行逻辑相关联的过程其实是构建某个Setting的过程，虽然咱们也能够将以上定义写成以下形式:
lazy val root = Project(id = "", base = file(".")).settings(Defaults.defaultSettings ++ Seq(hello := { println("hello, sbt~") }): _*)
但未免代码就太不雅观，也很差管理了(若是要添加多个自定义task，想一想，用这种形式是否是会让代码丑陋不堪那？！)，因此，咱们引入了helloTaskSetting这个标志常量来帮助咱们净化代码结构 ：）
万事俱备以后，就可使用咱们的自定义task了，使用定义Key的时候指定的task名称来调用它便可：
$ sbt hello hello, sbt~ // 或者 $ sbt > hello hello, sbt~ [success] Total time: 0 s, completed Oct 4, 2012 2:48:48 PM
怎么样？ 在SBT中自定义task是否是很简单那？！
每一个项目最终都要以相应的形式发布^[这里的发布更可能是指特殊的发布形式，好比提供完整的下载包给用户，直接打包成部署包等。通常状况下，若是用Maven或者SBT，能够直接publish到相应的Maven或者Ivy Repository中]，好比二进制包， 源码包，甚至直接可用的部署包等等， 假设咱们想把当前的SBT项目打包成可直接解压部署的形式，咱们可使用刚刚介绍的自定义task来完成这一工做:
object ProjectBuild extends Build { import Tasks._ lazy val root = Project(id = "", base = file(".")).settings(Defaults.defaultSettings ++ Seq(distTask, helloTaskSetting): _*) } object Tasks { val hello = TaskKey[Unit]("hello", "just say hello") val helloTaskSetting = hello := { println("hello, sbt~") } val dist = TaskKey[Unit]("dist", "distribute current project as zip or gz packages") val distTask = dist <<= (baseDirectory, target, fullClasspath in Compile, packageBin in Compile, resources in Compile, streams) map { (baseDir, targetDir, cp, jar, res, s) => s.log.info("[dist] prepare distribution folders...") val assemblyDir = targetDir / "dist" val confDir = assemblyDir / "conf" val libDir = assemblyDir / "lib" val binDir = assemblyDir / "bin" Array(assemblyDir, confDir, libDir, binDir).foreach(IO.createDirectory) s.log.info("[dist] copy jar artifact to lib...") IO.copyFile(jar, libDir / jar.name) s.log.info("[dist] copy 3rd party dependencies to lib...") cp.files.foreach(f => if (f.isFile) IO.copyFile(f, libDir / f.name)) s.log.info("[dist] copy shell scripts to bin...") ((baseDir / "bin") ** "*.sh").get.foreach(f => IO.copyFile