Reputation: 6811
Using SBT 0.13.13, our build definition is inherited from an older project. Currently there are a build.sbt and some project/*.scala files. These scala files follow the same pattern. Here is an example:
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 says
In the previous versions of sbt, .scala was the only way to create multi-project build definition
Question: I suppose this mean the use of separate project/*.scala files is discouraged. If so, is it OK to move the code of these *.scala file and put them all in build.sbt?
Upvotes: 0
Views: 238
Reputation: 4411
There is little functional difference between having code in project/
and code in build.sbt
.
The advantage to putting code in a .scala
file in project/
is that all symbols in it are imported into the namespace of all build.sbt
files in all subprojects of your build. This means that helper methods, constants, plugins, or other Scala code can live in a single location, but be called from anywhere.
Ultimately, whether to use this features comes down to whether you want shared items configured in a single location, or in multiple locations.
If you prefer to have your project settings configured entirely in separate build.sbt
files in their subproject directories, putting shared settings in the project/
folder is the way to do that.
If you're OK with having shared settings configured in the root build.sbt
file (or if you don't use any subproject build.sbt
files), you can consolidate all of your shared configuration into it.
Upvotes: 0