How to pass project to a task? - sbt

I'm writing a Task that needs access to the Project - it needs to iterate through the dependencies to do some side-effect specific to our build. I need to be able to work out transitive internal and external dependencies (i.e. modules and jars) of children modules of thisProject.
I'm currently doing something like this to pass the other things that I need (name and Ivy-managed deps via libraryDependencies):
myTask := runMyTask(
(name in Compile).value,
(libraryDependencies in Compile).value
)
I still need another parameter like
(project in Compile)
but such a key does not exist.
How am I supposed to get the Project?
NB I realise this is probably not possible - without an evil hack involving named lookup of projects from a manually maintained hashmap - because of the Project/Task/Phase axis, but worth asking anyway in case there is a clean solution.

Use thisProject or any other lazy val that you've defined in the build.
> help thisProject
Provides the current project for the referencing scope.
> inspect thisProject
[info] Setting: sbt.ResolvedProject = Project(id runtime-assembly, base: C:\dev\sandbox\runtime-assembly, configurations: List(compile, runtime, test, provided, optional), plugins: List(<none>), autoPlugins: List(sbt.plugins.CorePlugin, sbt.plugins.IvyPlugin, sbt.plugins.JvmPlugin, sbt.plugins.JUnitXmlReportPlugin))
[info] Description:
[info] Provides the current project for the referencing scope.
[info] Provided by:
[info] {file:/C:/dev/sandbox/runtime-assembly/}runtime-assembly/*:thisProject
[info] Defined at:
[info] (sbt.Load) Load.scala:210
[info] Reverse dependencies:
[info] *:ivyConfigurations
[info] *:name
[info] *:organization
[info] *:cacheDirectory
[info] *:baseDirectory
[info] Delegates:
[info] *:thisProject
[info] {.}/*:thisProject
[info] */*:thisProject
Give it a try in consoleProject as follows:
> consoleProject
[info] Starting scala interpreter...
[info]
import sbt._
import Keys._
import dsl._
import _root_.org.sbtidea.SbtIdeaPlugin._
import _root_.de.johoop.jacoco4sbt.JacocoPlugin._
import _root_.com.timushev.sbt.updates.UpdatesPlugin._
import _root_.sbtassembly.Plugin._
import _root_.sbt.plugins.IvyPlugin
import _root_.sbt.plugins.JvmPlugin
import _root_.sbt.plugins.CorePlugin
import _root_.sbt.plugins.JUnitXmlReportPlugin
import currentState._
import extracted._
import cpHelpers._
Welcome to Scala version 2.10.4 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_60).
Type in expressions to have them evaluated.
Type :help for more information.
scala> thisProject
res0: sbt.SettingKey[sbt.ResolvedProject] = sbt.SettingKey$$anon$4#1f3eff94
scala> thisProject.eval
res1: sbt.ResolvedProject = Project(id runtime-assembly, base: C:\dev\sandbox\runtime-assembly, configurations: List(compile, runtime, test, provided, optional), plugins: List(<none>), autoPlugins: List(sbt.plugins.CorePlugin, sbt.plugins.IvyPlugin, sbt.plugins.JvmPlugin, sbt.plugins.JUnitXmlReportPlugin))
scala> thisProject.eval.dependencies
res2: Seq[sbt.ClasspathDep[sbt.ProjectRef]] = List()
There's also configurations field that holds a list of available configurations for the project. Use it if you need to query for the value of a setting, say libraryDependencies, across configurations.
scala> thisProject.eval.configurations
res3: Seq[sbt.Configuration] = List(compile, runtime, test, provided, optional)
You may also want to read about ScopeFilter in Getting values from multiple scopes "that gets values from multiple scopes". Including a sample from the page:
lazy val core = project
lazy val util = project
lazy val root = project.settings(
sources := {
val filter = ScopeFilter(inProjects(core, util), inConfigurations(Compile))
// each sources definition is of type Seq[File],
// giving us a Seq[Seq[File]] that we then flatten to Seq[File]
val allSources: Seq[Seq[File]] = sources.all(filter).value
allSources.flatten
}
)

Related

How to start scala REPL with classes from subprojects included?

I have a project admp which aggregates 3 subprojects:
lazy val admp = (project in file("."))
.aggregate(common, regression, integration)
.settings(commonSettings)
When I execute test:console command then test classes from subprojects are not included:
sbt:admp> test:console
[info] Starting scala interpreter...
Welcome to Scala 2.11.9 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_151).
Type in expressions for evaluation. Or try :help.
scala> import me.enreach.qa.Aerospike._
<console>:11: error: not found: value me
import me.enreach.qa.Aerospike._
^
Only when I run common/test:console command then it loads the classes:
sbt:admp> common/test:console
[info] Starting scala interpreter...
Welcome to Scala 2.11.9 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_151).
Type in expressions for evaluation. Or try :help.
scala> import me.enreach.qa.Aerospike._
import me.enreach.qa.Aerospike._
import me.enreach.qa.Aerospike._
Is there a way to load classes from all sub-projects?
You can achieve it by adding dependencies on your subprojects in the test scope. Add this to your admp project definition:
.dependsOn(
common % "test->test",
regression % "test->test",
integration % "test->test"
)
This way you say that admp's test configuration depends on each subproject's test configuration. You can read more in sbt docs about configurations mapping.
Now when you run admp/test:console you should have access to all subprojects' test sources.

What does extend for a configuration do?

In SBT I create a new config, called katebush, as follows:
lazy val KateBush: Configuration = config("katebush")
When I try to run katebush:compile I get an error. That's what I expect.
> katebush:compile
[error] No such setting/task
[error] katebush:compile
[error] ^
Now I extend Compile in my config definition, and I expect to pick up the compile from the inherited scope.
lazy val KateBush: Configuration = config("katebush") extend Compile
Except it doesn't work:
> katebush:compile
[error] No such setting/task
[error] katebush:compile
[error] ^
But if I add in the defaults to the config (in build.sbt) so it looks as follows:
lazy val KateBush: Configuration = config("katebush") extend Compile
inConfig(KateBush)(Defaults.compileSettings)
it works fine:
> katebush:compile
[info] Updating {file:/Users/jacek/sandbox/so-25596360/}so-25596360...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[success] Total time: 0 s, completed Aug 31, 2014 11:35:47 PM
So, my question is, what exactly does extend for a configuration do?
DISCLAIMER I've got a rather basic understanding of the config concept of sbt.
tl;dr Extending a configuration is solely to inherit the dependencies groups not settings.
From the sources of final case class Configuration:
def extend(configs: Configuration*) = Configuration(name, description, isPublic, configs.toList ::: extendsConfigs, transitive)
By default, extendsConfigs is Nil as can be seen in the sbt.Configurations object:
def config(name: String) = new Configuration(name)
that resolves to (note Nil)
def this(name: String) = this(name, "", true, Nil, true)
In sbt.IvySbt.toIvyConfiguration:
import org.apache.ivy.core.module.descriptor.{ Configuration => IvyConfig }
and that's where the support of the config concept ends in sbt and Ivy steps in. That's where you'd have to look at the documentation of Ivy.
But before that read Advanced configurations example where it says:
This is an example .scala build definition that demonstrates using Ivy
configurations to group dependencies.
That's the beginning of the explanation. Ivy configurations are to group dependencies and extending a configuration is to extend the grouping.
From the official documentation of Ivy about the conf element:
a configuration is a way to use or construct a module.(...)
a module may need some other modules and artifacts only at build time, and some others at runtime. All those differents ways to use or build a module are called in Ivy module configurations.
Reading along you can find the answer to your question (that I'm myself yet to digest, too):
A configuration can also extend one or several other ones of the same
module. When a configuration extends another one, then all artifacts
required in the extended configuration will also be required in the
configuration that extends the other one. For instance, if
configuration B extends configuration A, and if artifacts art1 and
art2 are required in configuration A, then they will be automatically
required in configuration B. On the other hand, artifacts required in
configuration B are not necessarily required in configuration A.
This notion is very helpful to define configurations which are similar
with some differences.
At the bottom of the page, there's the Examples section with an example with runtime config that has "runtime will be composed of all dependencies, all transitively, including the dependencies declared only in compile."
With this, you can now understand the config concept in sbt as a dependencies groups and what's grouped in Compile is available in Runtime as its definition looks as follows:
lazy val Runtime = config("runtime") extend (Compile)
I have just had to figure this out, so I thought this was worth clarifying. The configuration has to be added to the project for delegation to the extended configuration to occur:
lazy val KateBush: Configuration = config("katebush") extend Compile
lazy val root = (project in file(".")).configs(KateBush)
will work fine. If you
inspect katebush:compile
then you can view the delegation chain:
...
[info] Delegates:
[info] katebush:compile
[info] compile:compile
[info] *:compile
[info] {.}/katebush:compile
[info] {.}/compile:compile
[info] {.}/*:compile
[info] */katebush:compile
[info] */compile:compile
[info] */*:compile
...

How to develop sbt plugin in multi-project build with projects that use it?

Is it possible to build an sbt plugin in a multi-project setup and use that plugin in some other sub-project of the same multi-project?
For example:
root/
+ mySbtPlugin/
+ myProject/
+ project/
+ plugins.sbt // Uses `mySbtPlugin`
It is not possible since the only way to define plugins for a single or multi-module project is via project (meta)build. I was tricked again to have a solution for you when I set up the sandbox environment with the layout you described.
sbt allows project (meta)project to be in the root directory only. No other project directories are processed and become part of the build definition.
That's why your best (and only) bet is to have the multi-module build for myProject and mySbtPlugin to ease your development, and enable the plugin only for these project(s) you really want to (be careful with auto-plugins, though).
project/plugins.sbt
lazy val root = (project in file(".")) dependsOn sbtNonamePlugin
lazy val sbtNonamePlugin = ProjectRef(file("../sbt-noname"), "sbt-noname")
addSbtPlugin("pl.japila" % "sbt-noname" % "1.0")
build.sbt
lazy val `my-project`, `sbt-noname` = project
sbt-noname/build.sbt
sbtPlugin := true
name := "sbt-noname"
organization := "pl.japila"
version := "1.0"
sbt-noname/src/main/scala/sbtnoname/Plugin.scala
package sbtnoname
import sbt._
import plugins._
object Plugin extends AutoPlugin {
override def trigger = allRequirements
override val projectSettings: Seq[Setting[_]] = inConfig(Test)(baseNonameSettings)
lazy val sayHello = taskKey[Unit]("Say hello")
lazy val baseNonameSettings: Seq[sbt.Def.Setting[_]] = Seq(
sayHello := {
println("I'm the plugin to say hello")
}
)
}
With the files above, run sbt.
> about
[info] This is sbt 0.13.6-SNAPSHOT
[info] The current project is {file:/Users/jacek/sandbox/multi-plugin/}my-project 0.1-SNAPSHOT
[info] The current project is built against Scala 2.10.4
[info] Available Plugins: sbt.plugins.IvyPlugin, sbt.plugins.JvmPlugin, sbt.plugins.CorePlugin, sbt.plugins.JUnitXmlReportPlugin, sbtnoname.Plugin, com.timushev.sbt.updates.UpdatesPlugin
[info] sbt, sbt plugins, and build definitions are using Scala 2.10.4
> projects
[info] In file:/Users/jacek/sandbox/multi-plugin/
[info] * multi-plugin
[info] my-project
[info] sbt-noname
> plugins
In file:/Users/jacek/sandbox/multi-plugin/
sbt.plugins.IvyPlugin: enabled in multi-plugin, sbt-noname, my-project
sbt.plugins.JvmPlugin: enabled in multi-plugin, sbt-noname, my-project
sbt.plugins.CorePlugin: enabled in multi-plugin, sbt-noname, my-project
sbt.plugins.JUnitXmlReportPlugin: enabled in multi-plugin, sbt-noname, my-project
sbtnoname.Plugin: enabled in multi-plugin, sbt-noname, my-project
> my-project/test:sayHello
I'm the plugin to say hello
[success] Total time: 0 s, completed Jun 15, 2014 3:49:50 PM

How to exclude files in a custom clean task?

I'm working on a custom TaskKey that makes a clean that keeps a folder in target directory - it's a database that I don't want to fill everytime.
So I tried something like that:
lazy val cleanOutput = taskKey[Unit]("Prints 'Hello World'")
cleanOutput := clean.value
cleanKeepFiles in cleanOutput <+= target { target => target / "database" }
It seems that the statement in cleanOutput is not taken in consideration.
Even when I do just the following it doesn't work:
cleanKeepFiles in clean <+= target { target => target / "database" }
But the following works:
cleanKeepFiles <+= target { target => target / "database" }
Why is the difference?
There are keys, which may have defined values in different scopes (project, configuration or task).
A key can be defined, even if it's not used in any scope, as well as a key can be given a value in any scope. The later doesn't mean that the value will be used by a specific task. It means you can reuse keys declared by sbt for your purposes.
What you do you declare a new taskKey. You define your task to call clean. You then define cleanKeepFiles in the scope of your new task to equal to whatever the value was before, plus your database directory in the target.
The value is set correctly, but the clean task will not look for it in the scope of your task.
You can verify it:
> show cleanOutput::cleanKeepFiles
[info] List(/home/lpiepiora/Desktop/sbt/stack-overflow/q-24020437/target/.history, /home/lpiepiora/Desktop/sbt/stack-overflow/q-24020437/target/database)
Additionally you can check:
> inspect *:cleanKeepFiles
[info] Setting: scala.collection.Seq[java.io.File] = List(/home/lpiepiora/Desktop/sbt/stack-overflow/q-24020437/target/.history)
[info] Description:
[info] Files to keep during a clean.
[info] Provided by:
[info] {file:/home/lpiepiora/Desktop/sbt/stack-overflow/q-24020437/}q-24020437/*:cleanKeepFiles
[info] Defined at:
[info] (sbt.Defaults) Defaults.scala:278
[info] Dependencies:
[info] *:history
[info] Reverse dependencies:
[info] *:clean
[info] Delegates:
[info] *:cleanKeepFiles
[info] {.}/*:cleanKeepFiles
[info] */*:cleanKeepFiles
[info] Related:
[info] *:cleanOutput::cleanKeepFiles
You can also see that sbt knows, that you have set it in the scope *:cleanOutput::cleanKeepFiles, it is just not using it.
Where it will look for it?. You can check it by inspecting the clean task.
> inspect clean
[info] Task: Unit
[info] Description:
[info] Deletes files produced by the build, such as generated sources, compiled classes, and task caches.
// next lines are important
[info] Dependencies:
[info] *:cleanKeepFiles
[info] *:cleanFiles
You can see that one of the dependencies is *:cleanKeepFiles, the * means Global configuration. This means that the clean task will look for the setting in that scope. You can change your setting to:
cleanKeepFiles += target.value / "database"
This will set it in the correct scope used by the clean task.
Edit
There is a doClean function which you can reuse. Given that, you can define your clean task like this:
val cleanKeepDb = taskKey[Unit]("Cleans folders keeping database")
cleanKeepDb := Defaults.doClean(cleanFiles.value, (cleanKeepFiles in cleanKeepDb).value)
cleanKeepFiles in cleanKeepDb += target.value / "database"

SBT Config extend vs DefaultSettings

If I define an SBT config with
val MyConfig = config("my") extend Test
is that basically the same as doing
val MyConfig = config("my")
val mySettings = inConfig(MyConfig)(Defaults.testSettings)
and then importing mySettings inside a build definition ?
No, calling extend method is not the same thing as calling inConfig. extend just returns a new configuration with passed in configurations prepended extendsConfigs, and it will not introduce any new settings.
When you add MyConfig into the project, it becomes part of the scoped key resolution path:
val MyConfig = config("my") extend Test
val root = (project in file(".")).
configs(MyConfig)
Suppose you type my:test in the sbt shell. Since test task is not found under my configuration, it will traverse extendsConfigs and check if the tasks are available under them. The first one it's going to hit is Test since we prepended it. You can check this by running inspect my:test:
root> inspect my:test
[info] Task: Unit
[info] Description:
[info] Executes all tests.
[info] Provided by:
[info] {file:/Users/eugene/work/quick-test/sbt-so/}root/test:test
[info] Defined at:
[info] (sbt.Defaults) Defaults.scala:365
[info] Delegates:
[info] my:test
[info] test:test
[info] runtime:test
[info] compile:test
[info] *:test
[info] {.}/my:test
[info] {.}/test:test
[info] {.}/runtime:test
[info] {.}/compile:test
[info] {.}/*:test
[info] */my:test
[info] */test:test
[info] */runtime:test
[info] */compile:test
[info] */*:test
[info] Related:
[info] test:test
"Provided by" says it delegated to root/test:test. This mechanism allows you to share some of the settings but override others, but you still have to know the inner wiring of the settings scoped to tasks etc, so it's tricky business. You probably already know, but I'll link to Additional test configurations, which specifically discusses configurations for testing.

Resources