This undeprecates the syntax, but at the same times moves it out of
implicit scope, therefore requiring a 'import TupleSyntax._' to opt-in
to the old syntax.
This ports sbt-cross-building's cross (`^`) and switch (`^^`) commands.
Instead of making it a plugin, the default settings are now changed
to use `sbtVersion in pluginCrossBuild` for the sbt dependency.
In sbt 0.13.15, in addition to notifying the user about the existence of
sbt's shell, a feature was added to allow the user to switch to sbt's
shell - a more pro-active approach to just displaying a message.
Unfortunately sbt is often unintentionally invoked in shell scripts in
"interactive mode" when no interaction is expected by, for exmaple,
invoking `sbt package` instead of `sbt package < /dev/null`. In that
case hitting [ENTER] would silently trigger sbt to run its shell,
easily wrecking the script. In addition to that I was unhappy with the
implementation as it created a tight coupling between sbt's command
processing abstraction to sbt's shell command.
If you want to stay in sbt's shell after running a task like `package`
then invoke sbt like so:
sbt package shell
Fixes#3091
This is a change in strategy.
The motivation is the need to find a good balance between:
+ informing the uninformed that would benefit from this information, &
+ not spamming the already informed
Making it dependent on "compile" being present in remainingCommands will
probably make it trigger for, for example, Maven users who are used to
running "mvn compile" and always run "sbt compile", and who therefore
are unneccesarily suffering terribly slow compile speeds by starting up
the jvm and sbt every time.
Fixes#3091Fixes#3097
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
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.
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
This setting controls the maximum width of the ASCII graphs printed
by commands like `inspect tree`. Default value corresponds to the
previously hardcoded value of 40 characters.
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.
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/
Fixes#2198 Ref #2854
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.
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.
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
)
to check all resolvers to find the latest snapshot artifacts.
This behavior did not work well with Maven repositories where sbt was
failing to calculate the correct publication dates.
Now that #2075 fixes the Maven integration issue we should enable this
flag back again.
The build user can opt out by:
updateOptions := updateOptions.value.withLatestSnapshots(false)
Adds a new setting `useJCenter`, which is set to `false` by default.
When set to `true`, JCenter will be placed as the first external
resolver to find library dependencies.
The implementation of `externalResolvers` is changed to incorporate the
setting by calling `Resolver.reorganizeAppResolvers`. These changes
were required because `externalResolvers` uses whatever that's in the
launchconfig, which the build user may not upgrade.
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.
Forward-port of #2338.
Include sbt-ivy-snapshots to launchconfig
Prior to this change, the launchconfig for sbt was generated using
Transform's resource generator so releases would include
`typesafe-ivy-releases` repo, and snapshot releases would include
`typesafe-ivy-snapshots` and `sonatype-snapshots` repos in addition.
This is no longer useful since nightly builds are now published to
`sbt-ivy-snapshots` instead, which is backed by Bintray.
This removes the switching logic, so both `typesafe-ivy-releases` and
`sbt-ivy-snapshots` repos are always included into the launchconfig.
This removes the step of needing to download a launcher just to try the
nightly builds.
Forward-port of #2337.
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.
* origin/0.13.9:
Notes
0.13.9
cached resolution: use mutable map to speed up breakLoops
cached resolution: don't include callers from evicted modules
Add debug logs
Fixes#2129. break up circular dependency loops in cached resolution
try breaking circular dependency and continue sorting
refactored to use less stack space
make sortModules tailrec
Reproduce stack overflow using cached resolution with circular dependency
Simple remove-one method to workaround for circular dependency did not
work. This fix traverses the entire graph to detect all loops and then
breaks them up.
Eugene Yokota
Will Sargent
Dale Wijnand
James Koch
Guillaume Martres
valydia
ekrich
Roman Iakovlev
Josh Soref
Anatoly Fayngelerin
Ashley Mercer
kenji yoshida
James Roper
Tim Harper
Erik Bakker
Jesse Kinkead
Josh Suereth