sbt編譯入門

非託管依賴 爲放在 lib 目錄下的 jar 文件
託管依賴 配置在構建定義中，而且會自動從倉庫（repository）中下載
非託管依賴

大多數人會用託管依賴而非非託管依賴。可是非託管依賴在起步階段會簡單不少。

非託管依賴像這樣工做：將 jar 文件放在 lib 文件夾下，而後它們將會被添加到項目的 classpath 中。沒有更多的事情了！

你也能夠將測試依賴的 jar 文件放在 lib 目錄下，好比 ScalaCheck，Specs2，ScalaTest。

lib 目錄下的全部依賴都會在 classpaths（爲了 compile， test， run 和 console）。若是你想對其中的一個改變 classpath， 你須要作適當調整，例如 dependencyClasspath in Compile 或者dependencyClasspath in Runtime。

若是用非託管依賴的話，不用往 build.sbt 文件中添加任何內容，不過你能夠改變unmanagedBase key，若是你想用一個不一樣的目錄而非 lib。

用 custom_lib 替代 lib：

unmanagedBase := baseDirectory.value / "custom_lib"
baseDirectory 是項目的根目錄，因此在這裏你依據 baseDirectory 的值改變了 unmanagedBase，經過在 更多關於設置 中介紹的一個特殊的 value 方法。

同時也有一個列舉 unmanagedBase 目錄下全部 jar 文件的 task 叫 unmanagedJars。若是你想用多個目錄或者作一些更加複雜的事情，你可能須要用一個能夠作其它事情的 task 替換整個unmanagedJars task， 例如清空 Compile configuration 的列表，不考慮 lib 目錄下的文件：

unmanagedJars in Compile := Seq.empty[sbt.Attributed[java.io.File]]
託管依賴

sbt 使用 Apache Ivy 來實現託管依賴，因此若是你對 Ivy 或者 Maven 比較熟悉的話，你不會有太多的麻煩。

libraryDependencies Key

大多數時候，你能夠很簡單的在 libraryDependencies 設置項中列出你的依賴。也能夠經過 Maven POM 文件或者 Ivy 配置文件來配置依賴，並且能夠經過 sbt 來調用這些外部的配置文件。 你能夠從這裏獲取更詳細的內容。

像這樣定義一個依賴，groupId， artifactId 和 revision 都是字符串：

libraryDependencies += groupID % artifactID % revision
或者像這樣， 用字符串或者 Configuration val 當作 configuration：

libraryDependencies += groupID % artifactID % revision % configuration
libraryDependencies 在 Keys 中像這樣聲明：

val libraryDependencies = settingKeySeq[ModuleID]
方法 % 從字符串建立 ModuleID 對象，而後將 ModuleID 添加到 libraryDependencies 中。

固然，要讓 sbt（經過 Ivy）知道從哪裏下載模塊。若是你的模塊和 sbt 來自相同的某個默認的倉庫，這樣就會工做。例如，Apache Derby 在標準的 Maven2 倉庫中：

libraryDependencies += "org.apache.derby" % "derby" % "10.4.1.3"
若是你在 build.sbt 中輸入上面這些內容，而後執行 update，sbt 會將 Derby 下載到~/.ivy2/cache/org.apache.derby/。（順便提一下， compile 依賴於 update，因此 大多數時候不須要手動的執行 update。）

固然，你也能夠經過 ++= 一次將全部依賴做爲一個列表添加：

libraryDependencies ++= Seq(
groupID % artifactID % revision,
groupID % otherID % otherRevision
)
在不多狀況下，你也會須要在 libraryDependencies 上用 := 方法。

經過 %% 方法獲取正確的 Scala 版本

若是你用是 groupID %% artifactID % revision 而不是 groupID % artifactID % revision（區別在於 groupID 後面是 %%），sbt 會在 工件名稱中加上項目的 Scala 版本號。 這只是一種快捷方法。你能夠這樣寫不用 %%：

libraryDependencies += "org.scala-tools" % "scala-stm_2.11.1" % "0.3"
假設這個構建的 scalaVersion 是 2.11.1，下面這種方式是等效的（注意 "org.scala-tools" 後面是 %%）：

libraryDependencies += "org.scala-tools" %% "scala-stm" % "0.3"
這個想法是不少依賴都會被編譯以後給多個 Scala 版本，而後你想確保和項目匹配的某一個是二進制兼容的。

實踐中的複雜度在於一般一個依賴會和稍微不一樣的 Scala 版本一塊兒工做；可是 %% 就沒有那麼智能了。因此若是一個依賴要求版本爲 2.10.1，可是你使用的 scalaVersion := "2.10.4"， 你不可能使用 %% 方法即便 2.10.1 的版本頗有可能工做。若是 %% 中止工做了，只須要去檢查那個依賴是基於哪一個 Scala 版本構建的，而後硬編碼你認爲能夠工做的版本號（假設已經有一個）。

參見 交叉構建 獲取更多信息。

Ivy 修正

groupID % artifactID % revision 中的 revision 不須要是一個固定的版本號。Ivy 可以根據你指定的約束選擇一個模塊的最新版本。你指定 "latest.integration"，"2.9.+" 或者 "[1.0,)"，而不是 一個固定的版本號，像 "1.6.1"。參看Ivy 修訂文檔獲取詳細內容。

解析器

不是全部的依賴包都放在同一臺服務器上，sbt 默認使用標準的 Maven2 倉庫。若是你的依賴不在默認的倉庫中，你須要添加 resolver 來幫助 Ivy 找到它。

經過如下形式添加額外的倉庫：

resolvers += name at location
在兩個字符串中間有一個特殊的 at。

例如：

resolvers += "Sonatype OSS Snapshots" at "https://oss.sonatype.org/content/repositories/snapshots"
resolvers key 在 Keys 中像這樣定義：

val resolvers = settingKeySeq[Resolver]
at 方法經過兩個字符串建立了一個 Resolver 對象。

sbt 會搜索你的本地 Maven 倉庫若是你將它添加爲一個倉庫：

resolvers += "Local Maven Repository" at "file://"+Path.userHome.absolutePath+"/.m2/repository"
或者，爲了方便起見：

resolvers += Resolver.mavenLocal
參看法析器獲取更多關於定義其餘類型的倉庫的內容。

覆寫默認的解析器

resolvers 不包含默認的解析器，僅僅經過構建定義添加額外的解析器。

sbt 將 resolvers 和一些默認的倉庫組合起來構成 externalResolvers。

然而，爲了改變或者移除默認的解析器，你須要覆寫externalResolvers 而不是 resolvers。

Per-configuration dependencies

一般一個依賴只被測試代碼使用（在 src/test/scala 中，經過 Test configuration 編譯）。

若是你想要一個依賴只在 Test configuration 的 classpath 中出現而不是 Compile configuration，像這樣添加 % "test"：

libraryDependencies += "org.apache.derby" % "derby" % "10.4.1.3" % "test"
也可能也會像這樣使用類型安全的 Test configuration：

libraryDependencies += "org.apache.derby" % "derby" % "10.4.1.3" % Test
如今，若是你在 sbt 的命令提示行裏輸入 show compile:dependencyClasspath，你不該該看到 derby jar。可是若是你輸入 show test:dependencyClasspath， 你應該在列表中看到 derby jar。

一般，測試相關的依賴，如 ScalaCheck， Specs2和 ScalaTest 將會被定義爲 % "test"。

庫依賴更詳細的內容和技巧在這裏。

經常使用命令

actions – 顯示對當前工程可用的命令
update – 下載依賴
compile – 編譯代碼
test – 運行測試代碼
package – 建立一個可發佈的jar包
publish-local – 把構建出來的jar包安裝到本地的ivy緩存
publish – 把jar包發佈到遠程倉庫（若是配置了的話)
更多命令

test-failed – 運行失敗的spec
test-quick – 運行全部失敗的以及/或者是由依賴更新的spec
clean-cache – 清除全部的sbt緩存。相似於sbt的clean命令
clean-lib – 刪除lib_managed下的全部內容

SBT是Simple Build Tool的簡稱，若是讀者使用過Maven，那麼能夠簡單將SBT看作是Scala世界的Maven，雖然兩者各有優劣，但完成的工做基本是相似的。
雖然Maven一樣能夠管理Scala項目的依賴並進行構建， 但SBT的某些特性卻讓人如此着迷，好比：

使用Scala做爲DSL來定義build文件（one language rules them all）;
經過觸發執行(trigger execution)特性支持持續的編譯與測試；
增量編譯；^[SBT的增量編譯支持由於如此優秀，已經剝離爲Zinc，可被Eclipse, Maven,Gradle等使用]
能夠混合構建Java和Scala項目；
並行的任務執行；
能夠重用Maven或者ivy的repository進行依賴管理；
等等這些，都是SBT得以在Scala的世界裏廣受歡迎的印記。

SBT的發展能夠分爲兩個階段， 即SBT_0.7.x時代以及SBT_0.10.x之後的時代。

目前來說， SBT_0.7.x已經不多使用， 大部分公司和項目都已經遷移到0.10.x之後的版本上來，最新的是0.12版本。 0.10.x以後的版本build定義採用了新的Settings系統，與最初0.7.x版本採用純Scala代碼來定義build文件截然不同，雖然筆者在遷移以前很抵觸（由於0.7.x中採用Scala定義build文件的作法能夠體現很好的統一性），但仍是升級並接納了0.10.x之後的版本，而且也逐漸意識到， 雖然新的版本初看起來很複雜，但一旦瞭解了其設計和實現的哲學跟思路，就會明白這種設計能夠更便捷的定義build文件。並且可選的build文件方式也一樣運行採用Scala代碼來定義，即並未放棄統一性的思想。

以上是SBT的簡單介紹，若是讀者已經急於開始咱們的SBT之旅，那麼讓咱們先從SBT的安裝和配置開始吧！

SBT安裝和配置

SBT的安裝和配置能夠採用兩種方式，一種是全部平臺都通用的安裝配置方式，另外一種是跟平臺相關的安裝和配置方式，下面咱們分別對兩種方式進行詳細介紹。

全部平臺通用的安裝配置方式

全部平臺通用的安裝和配置方式只須要兩步：

下載sbt boot launcher
本書採用最新的sbt0.12，其下載地址爲http://typesafe.artifactoryonline.com/typesafe/ivy-releases/org.scala-sbt/sbt-launch/0.12.0/sbt-launch.jar；
建立sbt啓動腳本（啓動腳本是平臺相關的）
若是是Linux/Unit系統，建立名稱爲sbt的腳本，並賦予其執行權限，並將其加到PATH路徑中； sbt腳本內容相似於 java -Xms512M -Xmx1536M -Xss1M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=384M -jar dirname $0/sbt-launch.jar "$@"， 能夠根據狀況調整合適的java進程啓動參數；
若是是Windows系統，則建立sbt.bat命令行腳本，一樣將其添加到PATH路徑中。 腳本內容相似於set SCRIPT_DIR=%~dp0 \n java -Xmx512M -jar "%SCRIPT_DIR%sbt-launch.jar" %*
以上兩步便可完成sbt的安裝和配置。

平臺相關的安裝配置方式

筆者使用的是Mac系統，安裝sbt只須要執行brew install sbt便可（由於我已經安裝有homebrew這個包管理器），使用macport一樣能夠很簡單的安裝sbt - sudo port install sbt;

若是讀者使用的是Linux系統，那麼這些系統一般都會有相應的包管理器可用，好比yum或者apt，安裝和配置sbt也一樣輕鬆，只要簡單的運行yum install sbt 或者 apt-get install sbt命令就能搞定(固然，一般須要先將有sbt的repository添加到包管理器的列表中)；

Windows的用戶也能夠偷懶，只要下載MSI文件直接安裝，MSI文件下載地址爲http://scalasbt.artifactoryonline.com/scalasbt/sbt-native-packages/org/scala-sbt/sbt/0.12.0/sbt.msi。

以上方式基本上囊括三大主流操做系統特定的安裝和配置方式，其它特殊狀況讀者能夠酌情處理 ^_^

SBT基礎篇

既然咱們已經安裝和配置好了SBT，那就讓咱們先嚐試構建一個簡單的Scala項目吧！

Hello, SBT

在SBT的眼裏， 一個最簡單的Scala項目能夠極簡到項目目錄下只有一個.scala文件，好比HelloWorld.scala:

object HelloWorld{
def main(args: Array[String]) {
println("Hello, SBT")
}
}
假設咱們HelloWorld.scala放到hello目錄下，那麼能夠嘗試在該目錄下執行：

$ sbt

run
[info] Running HelloWorld
Hello, SBT
[success] Total time: 2 s, completed Sep 2, 2012 7:54:58 PM
怎麼樣，是否是很簡單那？ （畫外音： 這豈止是簡單，簡直就是個玩具嘛，有啥用嘛？！ 來點兒實在的行不？）

好吧， 筆者也認可這過小兒科了，因此，咱們仍是來點兒"乾貨"吧！

NOTE: 以上實例簡單歸簡單，但可不要小看它哦，你可知道筆者開始就由於忽略瞭如此簡單的小細節而"光陰虛度"？ 該實例的項目目錄下，沒有定義任何的build文件，卻依然能夠正確的執行sbt命令， 實際上， 即便在一個空目錄下執行sbt命令也是能夠成功進入sbt的console的。 因此，只要瞭解了sbt構建的這個最低條件，那麼，當你無心間在非項目的根目錄下執行了相應sbt命令而出錯的時候，除了檢查build文件的定義，另外要注意的就是，你是否在預想的項目根目錄下面執行的sbt命令！
SBT項目工程結構詳解

通常意義上講，SBT工程項目的目錄結構跟Maven的很像， 若是讀者接觸過Maven，那麼能夠很容易的理解以下內容。

一個典型的SBT項目工程結構以下圖所示：

src目錄詳解

Maven用戶對src目錄的結構應該不會感到陌生，下面簡單介紹各個子目錄的做用。

src/main/java目錄存放Java源代碼文件
src/main/resources目錄存放相應的資源文件
src/main/scala目錄存放Scala源代碼文件
src/test/java目錄存放Java語言書寫的測試代碼文件
src/test/resources目錄存放測試起見使用到的資源文件
src/test/scala目錄存放scala語言書寫的測試代碼文件
build.sbt詳解

讀者能夠簡單的將build.sbt文件理解爲Maven項目的pom.xml文件，它是build定義文件。 SBT運行使用兩種形式的build定義文件，一種就是放在項目的根目錄下，即build.sbt， 是一種簡化形式的build定義； 另外一種放在project目錄下，採用純Scala語言編寫，形式更加複雜，固然，也更完備，更有表現力。

咱們暫時先介紹build.sbt的定義格式，基於scala的build定義格式咱們稍後再細說。

一個簡單的build.sbt文件內容以下：

name := "hello" // 項目名稱

organization := "xxx.xxx.xxx" // 組織名稱

version := "0.0.1-SNAPSHOT" // 版本號

scalaVersion := "2.9.2" // 使用的Scala版本號

// 其它build定義
其中， name和version的定義是必須的，由於若是想生成jar包的話，這兩個屬性的值將做爲jar包名稱的一部分。

build.sbt的內容其實很好理解，能夠簡單理解爲一行表明一個鍵值對(Key-Value Pair)，各行之間以空行相分割。

固然，實際狀況要比這複雜，須要理解SBT的Settings引擎才能夠徹底領會， 以上原則只是爲了便於讀者理解build.sbt的內容。

除了定義以上項目相關信息，咱們還能夠在build.sbt中添加項目依賴：

// 添加源代碼編譯或者運行期間使用的依賴
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定義格式:

ivyXML :=











在這裏，咱們排除了某些沒必要要的依賴，而且聲明瞭某個定製過的依賴聲明。

固然， build.sbt文件中還能夠定義不少東西，好比添加插件，聲明額外的repository，聲明各類編譯參數等等，咱們這裏就不在一一贅述了。

project目錄即相關文件介紹

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目錄及其相關文件。

TIPS

在sbt0.7.x時代， 咱們只要建立項目目錄，而後在項目目錄下敲入sbt，則應該建立哪些須要的目錄和文件就會由sbt自動爲咱們生成， 而sbt0.10以後，這項福利就沒有了。 因此，剛開始，咱們可能會認爲要很苦逼的執行一長串命令來生成相應的目錄和文件：

$ touch build.sbt
$ mkdir src
$ mkdir src/main
$ mkdir src/main/java
$ mkdir src/main/resources
$ mkdir src/main/scala
$ mkdir src/test
$ mkdir src/test/java
$ mkdir src/test/resources
$ mkdir src/test/scala
$ mkdir project
$ ...

SBT的使用

SBT支持兩種使用方式：

批處理模式(batch mode)
可交互模式(interactive mode)
批處理模式是指咱們能夠在命令行模式下直接依次執行多個SBT命令， 好比:

$ sbt compile test package

而可交互模式則直接運行sbt，後面不跟任何SBT命令，在這種狀況下， 咱們將直接進入sbt控制檯(console)， 在sbt控制檯中，咱們能夠輸入任何合法的sbt命令並得到相應的反饋：

$ sbt

compile
[success] Total time: 1 s, completed Sep 3, 2012 9:34:58 PM
test
[info] No tests to run for test:test
[success] Total time: 0 s, completed Sep 3, 2012 9:35:04 PM
package
[info] Packaging XXX_XXX_2.9.2-0.1-SNAPSHOT.jar ...
[info] Done packaging.
[success] Total time: 0 s, completed Sep 3, 2012 9:35:08 PM

TIPS

在可交互模式的sbt控制檯下，能夠輸入help獲取進一步的使用信息。
在以上實例中，咱們依次執行了compile， test和package命令， 實際上， 這些命令之間是有依賴關係的，若是僅僅是爲了package，那麼，只須要執行package命令便可， package命令依賴的compile和test命令將先於package命令執行，以保證它們之間的依賴關係得以知足。

除了compile，test和package命令， 下面列出了更多可用的sbt命令供讀者參考:

compile
test-compile
run
test
package
這些命令在某些狀況下也能夠結合SBT的觸發執行(Trigger Execution)機制一塊兒使用， 惟一須要作的就只是在相應的命令前追加~符號好比:

$ sbt ~compile

原則上， ~和相應命令之間應該用空格分隔，不過對於通常的命令來說，直接前綴~也是能夠的，就跟咱們使用~compile的方式同樣。
SBT的依賴管理

在SBT中， 類庫的依賴管理能夠分爲兩類：

unmanaged dependencies
managed dependencies
大部分狀況下，咱們會採用managed dependencies方式來管理依賴關係，但也不排除爲了快速構建項目環境等特殊狀況下，直接使用unmanaged dependencies來管理依賴關係。

Unmanaged Dependencies簡介

要使用unmanaged dependencies的方式來管理依賴其實很簡單，只須要將想要放入當前項目classpath的jar包放到lib目錄下便可。

若是對默認的lib目錄看着不爽， 咱們也能夠經過配置來更改這個默認位置，好比使用3rdlibs:

unmanagedBase <<= baseDirectory { base => base / "3rdlibs" }
這裏可能須要解釋一下以上配置。 首先unmanagedBase這個Key用來表示unmanaged dependencies存放第三方jar包的路徑， 具體的值默認是lib， 咱們爲了改變這個Key的值， 採用<<=操做符， 根據baseDirectory的值轉換並計算出一個新值賦值給unmanagedBase這個Key， 其中， baseDirectory指的是當前項目目錄，而<<=操做符(實際上是Key的方法)則負責從已知的某些Key的值計算出新的值並賦值給指定的Key。

關於Unmanaged dependencies，通常狀況下，須要知道的基本上就這些。

Managed Dependencies詳解

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",
...)
Resovers簡介

對於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"