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
JEP-201 describes the new modularized Java Standard Library in Java 9.
By default, java.xml.bind is no longer on the default classpath; it needs
to be added explicitly with a JVM option `--add-modules java.xml.bind`,
or with a dependency declaration in the module-info.java file if you
package your own code up as a Jigsaw module.
This commit traps the linkage error and (reflectively) uses the
java.util.Base64, which is the recommended way to encode/decode
since 1.8.
This is the start of an effort to make SBT 0.13.x compatible
with JDK 9.
The system property java.ext.dirs no longer exists now that
JEP-220 has removed the extension and endorsed classpath
facilities. It is also forbidden to manually set this to
an empty string from the command line.
This commit treats the absense of this property as an
empty extension classpath.
This adds a macro-level hack to support += op for sourceGenerators and resourceGenerators using RHS of Initialize[Task[Seq[File]]].
When the types match up, the macro now calls `.taskValue` automatically.
Seems following the deprecation warning info and the website
documentation and avoiding the BuildCommon inputTask method avoids
whatever problem was causing it to fail... Strange.. but ok?
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
Dotty nightly builds are published to maven, so they end up in
configuration "default", not "compile". We still need to look into
"compile" when dotty is published locally.
You can test this using https://github.com/smarter/dotty-example-project
by updating the sbt version used in project/build.properties and by
replacing "0.1.1-SNAPSHOT" by a nightly version like
"0.1.1-20170109-be64643-NIGHTLY" in build.sbt
This test suddenly started failing for no reason at line 25, adding this
sleep seems to have fixed that. Every other publish was preceded by a
sleep in this test, so this makes some sense.
Before the previous commit, this failed with:
[error] (*:update) java.lang.IllegalArgumentException: a module is not
authorized to depend on itself: org.foo#scala-library;2.99.0
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.
Eugene Yokota
Dale Wijnand
Haochi Chen
Eric K Richardson
Jason Zaugg
Guillaume Martres