1. ascii-graphs
We need a 2.12 version of ascii-graphs. The last commit to the project is in June 2013 (https://github.com/mdr/ascii-graphs/graphs/contributors). We are now in October 2017. I opened a PR (https://github.com/mdr/ascii-graphs/pull/11) but I don't expect any progress on this front. We can maintain a fork or drop ascii-graphs.
2. ignoreMissingUpdate
ignoreMissingUpdate is a tricky one. Here is some explanation:
we need to duplicate the updateTask
in sbt it's define as:
```scala
def updateTask: Initialize[Task[UpdateReport]] = Def.task {
// ...
val uc0 = updateConfiguration.value
// ...
}
```
since it's not scoped to our task (ex: `updateConfiguration in ignoreMissingUpdate`) we cannot just do
```scala
updateConfiguration in ignoreMissingUpdate := {
updateConfiguration.value.withMissingOk(true)
}
```
For example, the following example yield `"u2: false"
```
val update2 = TaskKey[Unit]("update2", "...")
val update2Configuration = SettingKey[Boolean]("...")
update2 := Def.task {
val u2 = (update2Configuration in update2).value
println(s"u2: $u2")
}.value
update2Configuration := false
update2Configuration in update2 := true
```
3. cross publishing
We can use the ^ operator to publish. For example: `sbt "^ publish"` to publish for both sbt 0.13 and 1.0.
This adds a sbt.watch.mode system property that if set to 'polling' will
use PollingWatchService instead of WatchServiceAdapter (nio).
On macOS this will default to 'polling' and on all others 'nio'.
This is a temporary workaround for users affected by #3527
This adds a sbt.watch.mode system property that if set to 'polling' will
use PollingWatchService instead of WatchServiceAdapter (nio).
On macOS this will default to 'polling' and on all others 'nio'.
This is a temporary workaround for users affected by #3527
Ref #3606, #3611, and #3613
This removes unnecessary thunk for slash syntax.
The semantics using this approach is strictly better than the previous `in (ref, config, task)`. By removing the thunk, we retain `(a / b) / c == a / b / c`.
See the following example:
```scala
scala> import sbt._, Keys._
scala> val t: TaskKey[Unit] = (test in Test)
t: sbt.TaskKey[Unit] = TaskKey(This / Select(ConfigKey(test)) / This / test)
scala> ThisBuild / t
ThisBuild / t
res1: sbt.TaskKey[Unit] = TaskKey(Select(ThisBuild) / Select(ConfigKey(test)) / This / test)
scala> ThisBuild / t / name
ThisBuild / t / name
res2: sbt.SettingKey[String] = SettingKey(Select(ThisBuild) / Select(ConfigKey(test)) / Select(test) / name)
```
so far so good? Now look at this:
```
scala> scala> name in (ThisBuild, t)
name in (ThisBuild, t)
res3: sbt.SettingKey[String] = SettingKey(Select(ThisBuild) / This / Select(test) / name)
```
`Test` configuration knowledge is lost! For `in (..)` maybe it was ok because mostly we don't use unscoped keys, but that's the difference between `in (..)` and `/`.
Fixes#3605
In ca71b4b902 I went about fixing the
inexhaustive matching in Scope's resolveProjectBuild and
resolveProjectRef. Looking back the change was wrong.
For resolveProjectBuild the new implementation is less wrong, but still
not great, seeing as it doesn't actually do any build resolving.
For resolveProjectRef the new implementation now blows up instead of
lies. Which means it's less leneant, more "fail-fast".
isProjectThis is unused; remnant of the pre-AutoPlugin days when build
settings where defined in Plugin.settings.
Simon Schäfer
Guillaume Massé
Dale Wijnand
PanAeon
Dale Wijnand
eugene yokota
Michael Stringer
Johannes Rudolph
Antonio Cunei