When running the 'update' task in bash, the output is all collapsed onto one line.
On Windows, even using an ANSI capable shell, running 'update' spams the console.
Tested with dash in Ubuntu; ANSICON, Console2 and ConsoleZ in Windows.
* Create a new sbt.compiler.javac package
* Create new interfaces to control running `javac` and `javadoc` whether forked or local.
* Ensure new interfaces make use of `xsbti.Reporter`.
* Create new method on `xsbti.compiler.JavaCompiler` which takes a `xsbti.Reporter`
* Create a new mechanism to parse (more accurately) Warnings + Errors, to distinguish the two.
* Ensure older xsbti.Compiler implementations still succeed via catcing NoSuchMethodError.
* Feed new toolchain through sbt.actions.Compiler API via dirty hackery until we can break things in sbt 1.0
* Added a set of unit tests for parsing errors from Javac/Javadoc
* Added a new integration test for hidden compilerReporter key, including testing threading of javac reports.
Fixes#875, Fixes#1542, Related #1178 could be looked into/cleaned up.
This implements all stories from https://github.com/sbt/sbt/wiki/User-Stories%3A-Conflict-Warning.
When scalaVersion is no longer effective an eviction warning will display.
Scala version was updated by one of library dependencies:
* org.scala-lang:scala-library:2.10.2 -> 2.10.3
When there're suspected incompatibility in directly depended Java libraries,
eviction warnings will display.
There may be incompatibilities among your library dependencies.
Here are some of the libraries that were evicted:
* commons-io:commons-io:1.4 -> 2.4
When there's suspected incompatiblity in directly depended Scala libraries,
eviction warnings will display.
There may be incompatibilities among your library dependencies.
Here are some of the libraries that were evicted:
* com.typesafe.akka:akka-actor_2.10:2.1.4 -> 2.3.4
This also adds 'evicted' task, which displays more detailed eviction warnings.
Add scala 2.11 test/build verification.
* Add 2.11 build configuratoin to travis ci
* Create command which runs `safe` unit tests
* Create command to test the scala 2.11 build
* Update scalacheck to 1.11.4
* Update specs2 to 2.3.11
* Fix various 2.11/deprecation removals
and other changes.
Fix eval test failure in scala 2.11 with XML not existing.
1) non-default derived settings, if they produce anything, the settings
they produce must supersede previous assignents (in the settings seq)
to the same key.
2) even if a derived setting is scoped at a higher scope (e.g.
ThisBuild) the settings it produces are scoped at the intersection of
that (the defining) scope and the scope of the triggering dependency.
2 is particularly nice as it enables this behaviour:
derive(b in ThisBuild := a.value + 1)
a in project1 := 0
// a could be defined in all projects
==>
Now (b in project1).value == (a in project1).value + 1 == 1
and similarly in all other projects
all with a single derived setting
* Create a new EvaluateTaskConfig which gives us a bit more freedom
over changign config options to EvaluateTask in the future.
* Create adapted from old EvaluateTask to new EvaluateTask
* Add hooks into signals class to register/remote a signal listener
directly, rather than in an "arm" block.
* Create TaskEvaluationCancelHandler to control the strategy of
who/whom can cancel (sbt-server vs. sbt-terminal).
* Create a null-object for the "can't cancel" scenario so the
code path is exactly the same.
This commit does not wire settings into the build yet, nor does it
fix the config extractio methods.
We shouldn't assume that the qualifier of a `Select` is a
`SymTree`; it may be a `Block`. One place that happens
is after the transformation of named/defaults applications.
That causes the reported `NullPointerException'.
In any case, using `qual.symbol.pos` sense here; it yields the
position of the defintions *referred to* by `qual`, not the
position of `qual` itself.
Both problems are easily fixed: use `qual.pos` instead.
Fixes#1107
The qualifier of the `.value` call may contain `DefTree`s (e.g.
vals, defs) or `Function` trees. When we snip them out of the
tree and graft them into a new context, we must also call
`changeOwner`, so that the symbol owner structure and the tree
structure are coherent.
Failure to do so resulted in a crash in the compiler backend.
Fixes#1150
The qualifier of the `.value` call may contain `DefTree`s (e.g.
vals, defs) or `Function` trees. When we snip them out of the
tree and graft them into a new context, we must also call
`changeOwner`, so that the symbol owner structure and the tree
structure are coherent.
Failure to do so resulted in a crash in the compiler backend.
Fixes#1150