2017-03-01 6 views
0

SBT 0.13.13を使用すると、ビルド定義は古いプロジェクトから継承されます。現在、build.sbtとproject/*。scalaファイルがあります。これらのスカラーファイルは同じパターンに従います。次に例を示します。build.sbtとproject * .scalaファイルを混在させるにはbuild.sbtですべて統一する必要がありますか?

import sbt._ 
import sbt.Keys._ 

object Docs { 
    lazy val docTask = TaskKey[Unit]("docPackage", "Generate Scaladoc") 

    lazy val settings = Seq(
    docTask := { 
     val docs = (doc in Compile).value 
     IO.copyDirectory(docs, new java.io.File("src/main/resources/myapp-scaladoc"), overwrite = true) 
    }, 

    docTask := (docTask.dependsOn(doc in Compile)).value 
) 
} 

Appendix: .scala build definitionは、SBTの以前のバージョンでは

を言い、.scalaは マルチプロジェクトビルド定義

質問を作成するための唯一の方法だった :これは、別のプロジェクト/ *。scalaファイルの使用が推奨されないことを意味します。もしそうなら、これらの* .scalaファイルのコードを移動し、それらをbuild.sbtに入れても構いませんか?

答えて

0

project/のコードとbuild.sbtのコードとの機能的な違いはほとんどありません。

.scalaファイルのコードをproject/に入れる利点は、その中のすべてのシンボルが、ビルドのすべてのサブプロジェクトのすべてのbuild.sbtファイルの名前空間にインポートされることです。つまり、ヘルパーメソッド、定数、プラグイン、または他のScalaコードは、単一の場所に置くことができますが、どこからでも呼び出すことができます。

最終的には、この機能を使用するかどうかは、単一の場所または複数の場所で共有アイテムを構成するかどうかになります。

サブプロジェクトディレクトリにある別のファイルbuild.sbtにプロジェクト設定を完全に設定したい場合は、project/フォルダに共有設定を入れることがその方法です。

ルートbuild.sbtファイルで共有設定を構成しても問題ない場合(またはサブプロジェクトbuild.sbtファイルを使用しない場合)は、すべての共有設定をそのファイルに統合できます。

関連する問題