Backports #2741, Fixes#1041e93c445 added a feature called early command, which uses `--` as a
prefix to denote some commands that runs ahead of session loading.
While the feature might be useful especially for logging, `--` is too
useful just for this purpose.
In addition, this adds log level commands with single `-`, such as
-error to treat them as early commands; and keeps `--` variant for log
level for backward compatibility.
* Backport style changes in tests and Defaults.scala
This backports the scripted tests and Defaults.scala style changes to
use `build.sbt` and `:=`.
* Fix backport
* Deprecate the old operators `<<=`, `<+=`, and `<++=`
The no-longer-documented operators `<<=`, `<+=`, and `<++=` are
deprecated in anticipation of the removal in sbt 1.0. Ref #2711
For `<<=`, the suggested migration would be to use either `:=` or `~=`
operators. The RHS of `<<=` takes an `Initialize[_]` expression, which
can be converted to `:=` style by wrapping the expression in
parenthesis, and calling `.value` at the end.
This adds support to generate synthetic subprojects from an auto plugin.
In addition, a method called `projectOrigin` is added to distinguish
Organic, BuildExtra, ProjectExtra, and GenericRoot.
Calling the `.value` method on an input task returns `InputTask[A]`, which is completely unintuitive. I think it's basically a bug in `.value`. This change deprecates the `.value` call on input tasks, in preparation to the removal in sbt 1.0.
In most cases `.evaluated` should be called, which returns `A` by evaluating the task. Just in case `InputTask[A]` is needed, `inputTaskValue` method is now provided.
One of the motivation for doing this now is the deprecation of old operators `<<=`, which forces more users to convert to the `:=` style and potentially run into the `.value` behavior.
PR #2469 added build keys to tab completion, with the side effect of
considering as available candidate in key selection, thus making sbt
think that some inputs were ambiguous (e.g. `baseDirectory`): should it
apply to the current project or to the build level key?
This commit fixes this issue by improving the key selection:
- If there's no candidate, we return the default key
- If there's a single possible project level key, and zero or more
build level keys, then we select the project level key.
- If there are zero project level key, and a single build level key,
then we select the build level key
- If there are multiple candidates, sbt says that the input is
ambiguous.
Fixes#2707
This adds `new` command, which helps create a new build definition. The
`new` command is extensible via a mechanism called the template
resolver,
which evaluates the arbitrary arguments passed to the command to find
and run a template.
As a reference implementation [Giter8][g8] is provided as follows:
sbt new eed3si9n/hello.g8
This will run eed3si9n/hello.g8 using Giter8.
[g8]: http://www.foundweekends.org/giter8/
Ref #2634
updateSbtClassifiers uses an artificially created dependency graph set
in classifiersModule. The problem is that ivyScala instance is reused
from the outer scope that has the user project's scalaVersion as
demonstrated as follows:
scala> val is = (ivyScala in updateSbtClassifiers).eval
is: Option[sbt.IvyScala] =
Some(IvyScala(2.9.3,2.9.3,List(),true,false,true,org.scala-lang))
This change fixes#2686 by redefining ivyScala with scalaVersion and
scalaBinaryVersion scoped to updateSbtClassifiers task. The existing
scripted test was modified to reproduce the bug.
eugene yokota
Dale Wijnand
Jaroslaw Grabowski
Martin Duhem
Miles Sabin
xuwei-k
Paul Draper