Have sbt.version set in project/build.properties is a best practice
because it makes the build more deterministic and reproducible.
With this change sbt, after ensuring that the base directory is probably
an sbt project, writes out sbt.version in project/build.properties if it
is missing.
Fixes#754
This was already supported in the internal Scripted used by sbt but not
in the ScriptedPlugin. This is fixed by just copy-pasting the modified
parser. We will have to wait for sbt itself to be built using an sbt
with the upgraded ScriptedPlugin to be able to avoid the code duplication.
Notify & enable users to stay in sbt's shell on the warm JVM by hitting
[ENTER] while sbt is running.
Looks like this; first I run 'sbt about', then I hit [ENTER]:
$ sbt about
[info] !!! Executing in batch mode !!! For better performance, hit [ENTER] to remain in the sbt shell
[info] Loading global plugins from /Users/dnw/.dotfiles/.sbt/0.13/plugins
[info] Loading project definition from /s/t/project
[info] Set current project to t (in build file:/s/t/)
[info] This is sbt 0.13.14-SNAPSHOT
[info] The current project is {file:/s/t/}t 0.1.0-SNAPSHOT
[info] The current project is built against Scala 2.12.1
[info] Available Plugins: sbt.plugins.IvyPlugin, sbt.plugins.JvmPlugin, sbt.plugins.CorePlugin, sbt.plugins.JUnitXmlReportPlugin, sbt.plugins.Giter8TemplatePlugin
[info] sbt, sbt plugins, and build definitions are using Scala 2.10.6
>
>
Fixes#2987
Previously, when the dependency resolver (Ivy) encountered a Maven version range such as `[1.3.0,)`
it would go out to the Internet to find the latest version.
This would result to a surprising behavior where the eventual version keeps changing over time
*even when there's a version of the library that satisfies the range condition*.
This changes to some Maven version ranges would be replaced with its lower bound
so that when a satisfactory version is found in the dependency graph it will be used.
You can disable this behavior using the JVM flag `-Dsbt.modversionrange=false`.
Fixes#2954
Ref #2291 / #2953
Before this commit, using dotty in your sbt project required to add:
scalaCompilerBridgeSource := ("ch.epfl.lamp" % "dotty-sbt-bridge" %
scalaVersion.value % "component").sources()
in your build.sbt. We might as well automatically do this, this reduces
the boilerplate for using dotty in your project to:
scalaOrganization := "ch.epfl.lamp"
scalaVersion := "0.1.1-SNAPSHOT"
scalaBinaryVersion := "2.11" // dotty itself is only published as a
// 2.11 artefact currently
Fixes#2460Fixes#2851
Ref #2707, #2708, #2469
Unlike the previous attempts at fixing the handling of build-level
keys, this change does not change the main parsing logic, which uses
`getKey` to retrieve the key from the key map.
The fact that shell worked pre-0.13.11 means that the parsing was ok.
What this changes is just the "example" keys supplied to the parser so
the tab completion works.
Fixes#2198 Ref #PULL
Generated Junit-style XML reports now include a count of ignored,
skipped and pending tests; and individual tests are correctly flagged
with the <skipped/> element.
Fixes#1466 Ref #2786
Even after fixing the mediator issue, we still have spurious binary
version conflict warning that does not account for sandbox
configurations.
This change follows the scalaVersionConfigs work.
Fixes#2786. Ref #2634.
sbt 0.13.12 added Ivy mediator that enforces scalaOrganization and
scalaVersion for Scala toolchain artifacts.
This turns out to be a bit too aggressive because Ivy configurations
can be used as an independent dependency graph that does not rely on
the scalaVersion used by Compile configuration. By enforcing
scalaVersion in those graph causes runtime failure.
This change checks if the configuration extends Default, Compile,
Provided, or Optional before enforcing scalaVersion.
Fixes#2761
With sbt 0.13.13-RC1 rediscovered that the dependency pulled in from
Giter8 was affecting the plugins. To avoid this, this change splits up
the template resolver implementation to another module called
sbt-giter8-resolver, and it will be downloaded using Ivy into
`~/.sbt/0.13/templates/`, and then launched reflectively using Java as
the interface.
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.
Eugene Yokota
Dale Wijnand
Guillaume Martres
Haochi Chen
Eric K Richardson
Ashley Mercer
Miles Sabin
Jaroslaw Grabowski