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.
Def.make could take 10099ms for 100 subprojects. This would display
logs probably for projects with more than 10 subprojects, which might
pause for a few seconds during load.
When running a sbt script, this change lets the user on UNIX and
Windows platforms to use native file extensions like none/.sh or
.bat/.cmd. The code copies the file to the sbt boot/hash/src_managed
directory with a .scala extension.
It turns out that we can leverage the`FakeResolver` that has been
implemented to use with the static launcher, and resolve a "fake
compiler bridge" using it, rather than copying it from the resources.
This also has the advantage of not requiring to change the build
definition.
This commit introduces a new "static" launcher that does not use Ivy to
gather all the artifacts that it requires, but rather expect them to be
immediately available.
To be able to use sbt without Internet access, we add a new
`ComponentCompiler` that is able to retrieve the bridge sources from the
resources on classpath and compile it.
sbt's shell provided completion only for keys that were relative to a
defined project, but didn't provide completion for keys that belong to
the build definition only.
This commit fixes this issue by defining a new kind of `Parser` (from
which completions are generated) which runs its input simultaneously on
distinct parsers. We now define a parser for project-level keys and
another parser for build-level keys. These two parsers are eventually
combined, and we get the completions of both parsers.
Fixessbt/sbt#2460
Fixes#2464 and Fixes#2465
appResolvers is a set of resolvers specified in the launcher
configuration.
This list fluctuates depending on the version of sbt, and sbt 0.13.10
meant to stabilize it by weeding out JCenter even when it includes it,
which failed when I applied the filter on the wrong list. This should
correct it.
We are hiding a bug fix on global setting that was not importing auto
imports because fixing this via sbt/sbt#2399 breaks the source
compatibility: sbt/sbt#2415
I've split out the relevant portion of the scripted test into
global-settings, and marked it pending.
This addresses 0.13.10 regression, which currently warns users about
Maven incompatibility on a private configuration. This adds a config
class so the build user can control the level of the warning as well as
the target configuration to be monitored.
By default, we are only going to look at `Compile` and `Runtime`.
Previously, the autoimports for globally defined plugins were not
imported for global configuration files, although they were imported for
project configuration files.
This patch causes an additional plugin discovery phase to happen during
global config evaluation, so that auto-plugins can be detected and their
imports subsequently included.
Adds `trackInternalDependencies` and `exportToInternal` settings. These
can be used to control whether to trigger compilation of a dependent
subprojects when you call `compile`. Both keys will take one of three
values: `TrackLevel.NoTracking`, `TrackLevel.TrackIfMissing`, and
`TrackLevel.TrackAlways`. By default they are both set to
`TrackLevel.TrackAlways`.
When `trackInternalDependencies` is set to `TrackLevel.TrackIfMissing`,
sbt will no longer try to compile internal (inter-project) dependencies
automatically, unless there are no `*.class` files (or JAR file when
`exportJars` is `true`) in the output directory. When the setting is
set to `TrackLevel.NoTracking`, the compilation of internal
dependencies will be skipped. Note that the classpath will still be
appended, and dependency graph will still show them as dependencies.
The motivation is to save the I/O overhead of checking for the changes
on a build with many subprojects during development. Here's how to set
all subprojects to `TrackIfMissing`.
lazy val root = (project in file(".")).
aggregate(....).
settings(
inThisBuild(Seq(
trackInternalDependencies := TrackLevel.TrackIfMissing,
exportJars := true
))
)
The `exportToInternal` setting allows the dependee subprojects to opt
out of the internal tracking, which might be useful if you want to
track most subprojects except for a few. The intersection of the
`trackInternalDependencies` and `exportToInternal` settings will be
used to determine the actual track level. Here's an example to opt-out
one project:
lazy val dontTrackMe = (project in file("dontTrackMe")).
settings(
exportToInternal := TrackLevel.NoTracking
)
As described in #2336, I noticed that when using 0.13 nightly from
Bintray, sbt was unable to locate the compiler source.
Since `updateSbtClassifiers` is already set up to download sbt's own
sources, the `ivyConfiguration` should be reused. However, `compilers`
is a derived task, which is unable to depend on a scoped key.
To workaround this I had to create a new key called
`bootIvyConfiguration`. This should now use the metabuild's resolvers
to download the compiler bridge source.
Eugene Yokota
Dale Wijnand
Martin Duhem
xuwei-k
Paul Draper
Anatoly Fayngelerin
Miles Sabin
ekrich
Tim Harper
Guillaume Martres