Best place to declare own settings so I can access them from sbt shell and my .sbt and .scala build files? - sbt

My settings are declared in project/Utils.scala in an object BuildSupport and are made available in .sbt and .scala files with import BuildSupport._.
However, this doesn't work for sbt shell as seen in above screenshot since I can't import them there. For completeness sake, I have tried eval import BuildSupport._ but all that got me was <eval>:1: error: illegal start of simple expression.
How do I have to define own settings and tasks so I can access them from:
project/*.scala,
*.sbt and
sbt shell?
I assume defining them in an AutoPlugin would work, but I'd rather not have to go to that length. Is there any other way?

Declaring an adhoc AutoPlugin (https://www.scala-sbt.org/1.x/docs/Plugins.html) is the way to go.
Auto plugins ...
can define autoImport object, which is automatically included into build.sbt. This can be used for keys.
can define globalSettings, buildSettings, or projectSettings to inject settings and tasks either at the build-level or at the subproject level. This should become available in sbt shell.
A plugin doesn't have to be a published on its own. You can declare one inside project/*.scala like any other Scala object.
The plugin in the linked documentation is great for copy-pasting:
package sbthello
import sbt._
import Keys._
object HelloPlugin extends AutoPlugin {
override def trigger = allRequirements
object autoImport {
val helloGreeting = settingKey[String]("greeting")
val hello = taskKey[Unit]("say hello")
}
import autoImport._
override lazy val globalSettings: Seq[Setting[_]] = Seq(
helloGreeting := "hi",
)
override lazy val projectSettings: Seq[Setting[_]] = Seq(
hello := {
val s = streams.value
val g = helloGreeting.value
s.log.info(g)
}
)
}

Related

Additional resource generator with sbt native packager

I have a submodule, that is compiled by invoking external command. I would like to include generated file into jar. So I wrote a task:
```
myTask := {
import sys.process.stringSeqToProcess
Seq("my", "command") !
}
unmanagedResourceDirectories in Compile += baseDirectory.value / "dist"
cleanFiles <+= baseDirectory { base => base / "dist" }
Keys.`package` <<= (Keys.`package` in Compile) dependsOn npmBuildTask.toTask
and when I invoke mySubmodule/package task it works well. But when I invoke stage task from sbt-native-packager my task is ignored(is not executed).
There are a couple of options to solve this issue. I assume you want to add the dist folder to your resulting application jar.
Your configuration doesn't work because stage doesn't depend on package. This results npmBuildTask not being called.
1. Add dependency to stage
The easiest way to fix this is by simply adding the npmBuildTask as a dependency to stage
stage <<= stage dependsOn npmBuildTask.toTask
I wouldn't recommend this approach.
2. Resource generators
SBTs Resoure Generators are exactly defined for this purpose. An inline version could look like this
resourceGenerators in Compile += Def.task {
streams.value.log.info("running npm generator")
val base = (resourceManaged in Compile).value / "dist"
// A resource generator returns a Seq[File]. This is just an example
List("index.js", "test.js").map { file =>
IO.writeLines(base / file, List("var x = 1"))
base / file
}
}.taskValue
Or you could extract this in an AutoPlugin to separate the "what" and "how.
3. AutoPlugin and resource generators
Create project/NpmPlugin.scala and add the following content
import sbt._
import sbt.Keys._
import sbt.plugins.JvmPlugin
object NpmPlugin extends AutoPlugin {
override val requires = JvmPlugin
override val trigger = AllRequirements
object autoImport {
val npmBuildTask = TaskKey[Seq[File]]("npm-build-task", "Runs npm and builds the application")
}
import autoImport._
override def projectSettings: Seq[Setting[_]] = Seq(
// define a custom target directory for npm
target in npmBuildTask := target.value / "npm",
// the actual build task
npmBuildTask := {
val npmSource = (target in npmBuildTask).value
val npmTarget = (resourceManaged in Compile).value / "dist"
// run npm here, which generates the necessary values
streams.value.log.info("running npm generator")
// move generated sources to target folder
IO.copyDirectory(npmSource, npmTarget)
// recursively get all files in the npmTarget
(npmTarget ***).get
},
resourceGenerators in Compile += npmBuildTask.taskValue
)
}
The build.sbt will then look like this
name := "resource-gen-test"
version := "1.0"
enablePlugins(JavaAppPackaging)
Pretty clean :)
4. Use mappings
Last but not least you could use mappings. They are the low level detail that drives a lot of the package-generation in sbt. The main idea of this solution is to
Create a task that returns a mapping definition ( Seq[(File, String)] )
Append this to the appropriate mappings
The advantage of this approach is that you are more flexible where you want to put your mappings.
import sbt._
import sbt.Keys._
import sbt.plugins.JvmPlugin
import com.typesafe.sbt.SbtNativePackager.Universal
import com.typesafe.sbt.SbtNativePackager.autoImport.NativePackagerHelper._
object NpmMappingsPlugin extends AutoPlugin {
override val requires = JvmPlugin
override val trigger = AllRequirements
object autoImport {
val npmBuildTask = TaskKey[Seq[(File, String)]]("npm-build-task", "Runs npm and builds the application")
}
import autoImport._
override def projectSettings: Seq[Setting[_]] = Seq(
// define a custom target directory for npm
target in npmBuildTask := target.value / "npm" / "dist",
// the actual build task
npmBuildTask := {
val npmTarget = (target in npmBuildTask).value
// run npm here, which generates the necessary values
streams.value.log.info("running npm generator")
// recursively get all files in the npmTarget
// contentOf(npmTarget) would skip the top-level-directory
directory(npmTarget)
},
// add npm resources to the generated jar
mappings in (Compile, packageBin) ++= npmBuildTask.value,
// add npm resources to resulting package
mappings in Universal ++= npmBuildTask.value
)
}
As you can see in this approach we can easily add the resulting files to different mappings.
However I only recommend this approach if you need this kind of flexibility as it requires a bit more knowledge of native-packager.

How to obtain the value of scalacOptions for the meta-project in a plugin?

In the ensime-sbt plugin, we need to be able to obtain the compiler flags that the sbt process is using to compile the build definition (i.e. everything under project).
We have the State object, but I can't see any way to get the compiler flags, where are they?
Note: this is not the compile flags for the projects themselves, I mean only for the build definition.
e.g. say the project has this in the project/plugins.sbt
scalacOptions += "-Xfuture"
how can we read that from the plugin?
This is somewhat related to How to share version values between project/plugins.sbt and project/Build.scala?
You can generate a build file for the project. And, to do that, you have to add the plugin in both the meta-project and the meta-project for the meta-project.
import sbt._
import Keys._
object MyPlugin extends AutoPlugin {
object autoImport {
val scalacOptions4Meta = SettingKey[Seq[String]]("scalacOptions4Meta")
val mygenerator = TaskKey[Seq[File]]("mygenerator")
}
import autoImport._
override def trigger = allRequirements
override lazy val projectSettings = Seq(
mygenerator := {
val file = sourceManaged.value / "settings4Meta.scala"
val opts = (scalacOptions in Compile).value
.map(opt => "\"" + opt + "\"")
val content = s"""
import sbt._
import Keys._
object MyBuild extends Build {
lazy val root = Project("root", file("."))
.settings(
MyPlugin.autoImport.scalacOptions4Meta := Seq(${opts.mkString(",")})
)
}"""
IO.write(file, content)
Seq(file)
}
)
}
project/plugins.sbt:
addSbtPlugin("myplugin" % "myplugin" % "0.1-SNAPSHOT")
scalacOptions := Seq("-Xfuture")
sourceGenerators in Compile += mygenerator.taskValue
project/project/plugins.sbt:
addSbtPlugin("myplugin" % "myplugin" % "0.1-SNAPSHOT")

Include a simple val in sbt build files from global.sbt

I wish to set my version numbers externally across several build.sbt files through a single include file.
Within build.sbt I can do this
val base = "1.1"
version := base + ".8-SNAPSHOT"
This works fine as a first step.
According the the online help I should be able to create a file global.sbt in my ~/.sbt/0.13 folder
I created the file global.sbt with single line
val base = "1.1"
and removed the corresponding line from build.sbt
But when I start up my sbt I get "error: not found: value base"
So either it's not finding the global sbt or this form of global setting doesn't work.
Any suggestions as to how I can resolve this?
Can I make an explicit include command in my build.sbt files?
It seems from your test that vals in global ~/.sbt/0.13/*.sbt files don't propagate to local *.sbt files.
Here's a setup that works:
~/.sbt/0.13/plugins/VersionBasePlugin.scala
import sbt._, Keys._
object VersionBasePlugin extends AutoPlugin {
override def requires = plugins.CorePlugin
override def trigger = allRequirements
object autoImport {
val versionBase = settingKey[String]("version base")
}
import autoImport._
override def projectSettings = Seq(versionBase := "1.1")
}
and then in your build.sbt:
version := (versionBase.value + ".8-SNAPSHOT")
Does that work for you?

Imports and ill-behaved SBT plugins

I'm trying to define parsers in a build.sbt file.
I'm using this plugin, by adding this line in plugins.sbt:
addSbtPlugin("com.gilt" % "sbt-dependency-graph-sugar" % "0.7.4")
When specifiying this in build.sbt:
import sbt.complete.DefaultParsers._
val servers = token(
literal("desarrollo") |
literal("parametrizacion")
)
SBT complains with this error message:
reference to literal is ambiguous;
reference to token is ambiguous;
it is imported twice in the same scope by
import sbt.complete.DefaultParsers._
and import _root_.gilt.DependencyGraph._
How can I avoid this namespace clashing of basic SBT classes?.
One solution is this:
import sbt.complete.{DefaultParsers ⇒ DP}
import sbt.complete.DefaultParsers._
val servers = DP.token(
DP.literal("desarrollo") |
DP.literal("parametrizacion")
)
I don't fully like it, because it adds clutter.
The ideal solution is to hide unwanted imports.
This solution creates a new scope, so there's no interference with imports:
name := "MyProject"
{
import sbt.complete.DefaultParsers._
val servers = token(
"desarrollo" | "parametrizacion"
)
}

How to execute task that calls clean on subprojects without using aggregation?

I want make a take cleanAll that executes the clean task on a number of subprojects. I don't want to use aggregation just for the sake of clean.
We've run into issues with play's asset routes when we've been using submodules.
It's well documented how to create a new task, but how do I call a task on a subproject?
Based on the example by Jacek Laskowski I've come up with the following plugin that should be placed in your /project folder:
import sbt._
import sbt.AutoPlugin
import sbt.Keys._
import sbt.plugins.JvmPlugin
object CleanAllPlugin extends AutoPlugin {
val cleanAll = taskKey[Unit]("Cleans all projects in a build, regardless of dependencies")
override def requires = JvmPlugin
override def projectSettings = Seq(
cleanAllTask
)
def cleanAllTask = cleanAll := Def.taskDyn {
val allProjects = ScopeFilter(inAnyProject)
clean.all(allProjects)
}.value
}
The plugin can now be added to the root project for usage:
val main = Project("root", file("."))
.enablePlugins(CleanAllPlugin)
It can be executed in SBT by calling: cleanAll
Use the following build.sbt:
val selectDeps = ScopeFilter(inDependencies(ThisProject))
clean in Compile := clean.all(selectDeps).value
It assumes that the build.sbt file is in the project that has clean executed on itself and dependsOn projects.
If you need it in project/Build.scala, just add the following:
val selectDeps = ScopeFilter(inDependencies(ThisProject))
val cleanInSubprojects = Seq(
clean in Compile := clean.all(selectDeps).value
)
and add cleanInSubprojects to settings of every project:
// definition of a project goes here
.settings(cleanInSubprojects: _*)

Resources