#3088 attemped to fix the #3086, but by putting no slashes in `sbt.boot.properties` the launcher created by 0.13.15-* becomes incompatible for all previous sbt versions.
The uglier but backward compatible fix for #3086 is to use u3 format with three slashes. This on Windows will resolve to `file:///C:/Users/foo/.sbt/preloaded`, and on Mac and Linux `file:////root/.sbt/preloaded/`. Mac and Linux are both tolerant of extra slashes on the front:
```
> eval new File(new URL("file:////Users/foo/.sbt/preloaded/").toURI)
[info] ans: java.io.File = /Users/foo/.sbt/preloaded
```
On Mac and Linux, user.home should return `/home/foo`, resulting to `file:/home/foo`.
On Windows, user.home should return `C:\Users\foo`, resulting to `file:C:/Users/foo`.
Improve IO.toFile's handling for Windows, and use it for identifying resolvers.
This adds support to convert URL to File on Windows in several ways:
```
val u0 = new URL("file:C:\\Users\\foo/.sbt/preloaded")
val u1 = new URL("file:/C:\\Users\\foo/.sbt/preloaded")
val u2 = new URL("file://unc/Users/foo/.sbt/preloaded")
val u3 = new URL("file:///C:\\Users\\foo/.sbt/preloaded")
val u4 = new URL("file:////unc/Users/foo/.sbt/preloaded")
```
Note that `u0` and `u2` are something `new File(u.toURI)` won't handle. This also correctly handles UNC convention specified by Microsoft in https://blogs.msdn.microsoft.com/ie/2006/12/06/file-uris-in-windows/.
Fixes#3086Fixes#2150
+ Don't notify ScriptMain users by moving the logic to xMain
+ Only trigger shell if shell is a defined command
+ Use existing Shell/BootCommand strings instead of new ones
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.
The sbt/sbt-launcher-package doesn't invoke sbt with the "shell"
command. sbt has a mechanism for handling this in its "boot" command
that adds an "iflast shell" to the commands. Handle this when displaying
the "Executing in batch mode" warning.
Fixes#3004
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
Eugene Yokota
Dale Wijnand
Guillaume Martres
Lars Hupel
Haochi Chen
Eric K Richardson