Fixes#3784
For Ivy repos, sbt 1.x publishes source and scaladoc JARs under `compile` configuration with types `src` and `doc` respectively. The current 0.13 implementation of `autoPlugins(...)` is not filtering them out correctly, and ends up including a source JAR as a compiler plugin.
This no longer injects scalaVersion at the project level, which was interfering with crossScalaVersions delegation to ThisBuild scope.
Fixessbt/sbt#3353
Both the default settings and ^^ together sets the correct scalaVersion based on `sbtVersion in pluginCrossBuild`, but frequently people set up `scalaVersion` on sbt plugin's subproject, which disables the feature.
This change appends the scalaVersionSetting on ^^ so scalaVersion gets switched to 2.12.2 on ^^ 1.0.0-RC2 etc.
Fixes#3205
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#3091
Specifically:
* Make them both commands, so they run after early commands (--error).
* Make notifyUsersAboutShell aware of "iflast shell" instead of "boot".
* Make writeSbtShell use a logger and tweak the message
Refs #3091
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.
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
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
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.