Set sbt.task.timings=true to print timings for tasks.
This sample progress handler shows how to get names for tasks and
deal with flatMapped tasks. There are still some tasks that make
it through as anonymous, which needs to be investigated.
A setting to provide a custom handler should come in a subsequent commit.
* Consolidate project ID validation and normalization into Project methods
* Provide an earlier and more detailed error message when the directory
name can't be used for the project ID
Construction of Scala providers was already properly synchronized jvm and machine-wide.
The cache on top of construction was not and neither was the newer ClassLoaderCache.
This could cause the same Scala version to be loaded in multiple class loaders, taking
up more permgen space and possibly decreasing performance due to less effective jit.
The issue is very rare in practice for 0.13 because of the low probability of contention
on ClassLoaderCache. This is because the work for a cache miss is mainly the construction
of a URLClassLoader. In 0.12, however, the work potentially involved network access and
class loading (not just class loader construction), thus greatly increasing the probability
of contention and thus duplicate work (i.e. class loader construction).
When there is contention, multiple class loaders are constructed and then preserved by the
scalaInstance task in each project throughout the first task execution. Only when multiple
scalaInstance tasks execute simultaneously and only during the first execution does this occur.
(Technically, it could still happen later, but it doesn't in practice.)
This means that the number of duplicate class loaders should quickly saturate instead of growing
linearly with the number of projects. It also means that the impact depends on the exact
tree structure of projects. A linear chain of dependencies will be unaffected, but a build with
independent leaves may be limited by the number of cores. The number of cores affects
the number of threads typically used by the task engine, which limits the number of concurrently
executing scalaInstance tasks.
In summary, this might affect the first, cold compilation of a multi-module project with
independent leaves on a multi-core machine with Scala version different from the version used
for sbt. It might increase the maximum permgen requirements as well as slow the jit compilation
by up to one task execution. Subsequent compilations should be unaffected and the permgen
utilization return to be as expected.
The Help for these commands now needs to be cleaned up, since they were not written with
this feature in mind. In particular,
* consider adding syntax summaries in the short help strings
* alternatively, add the syntax summary data elsewhere for use specifically by this feature
* display a better message when there is no short help string, such as
"See 'help <command>' for usage." or just displaying the lower level error message, such as
"Expected whitespace"
Support a definitive flag for Failure that ignores later failures
instead of appending them. This is useful to override the default
behavior of listing the failures of alternative parsers.
The reported issue was a JLine class not being found on sbt startup.
JLine was depended on in the sbt build in two places, one with an extra
attribute (component) and one without. The retrieve pattern used by the
launcher includes that extra attribute. Previously, the dependency
without the attribute was selected and jline properly ended up on the sbt
classpath. Now, either by bumping JLine to 2.11 or some other
insignificant change, jline ends up in a subdirectory for the component
and doesn't get on the classpath.
(The move in 0.10 away from retrieving based on patterns and
using things directly from the cache was good, but this can't be
used in the launcher until a hash-based artifact is used so that
sbt+Scala jars aren't deleted or overwritten while sbt runs.)
A secondary issue was that the compiler-interface-src artifact didn't have
a configuration and was therefore not included in the published artifacts.