Before 7992dc9, a custom, non-cached-resolution-aware update task was
used to generate the report that the tree is based on, effectively
ignoring the cached resolution flag at the project level.
Starting 7992dc9, this plugin, when run with sbt 0.13.8 or sbt 1.2.5+,
relies on cached-resolution-backed reports for projects that have
the engine enabled via `updateOptions`. Other 1.x releases are not
directly impacted as sbt had a buggy implementation of the feature
anyway, see https://github.com/sbt/sbt/issues/3761.
Cached resolution has the side effect of generating an ivy report
with artificial module descriptors which makes it hard to reconstruct
the tree without inlining sbt internals (see below), so this
effectively ignores it *for the purpose of the tree generation*, even
if the project enabled it for the regular report.
ModuleId(
org.scala-sbt.temp,
temp-resolve-e2a956132f02c038285b41b374c02f5838076f37,
1.0
)
https://github.com/sbt/librarymanagement/blob/984de6f/ivy/src/main/scala/sbt/internal/librarymanagement/ivyint/CachedResolutionResolveEngine.scala#L137
During refactoring, these warnings got out of date. I also added
scaladoc to the watchTriggeredMessage key.
Ref: https://github.com/sbt/sbt/issues/5051.
To avoid reliance on jvm global variables, we need to share the super
shell state with each of the console appenders that write to the console
out. We only set the progress state for the console appenders for the
screen. This prevents messages that are below the global logging level
from modifying the progress state without preventing them from being
written to other appenders.
The ability to set the ProgressState for each of the console appenders
is added in a companion util PR.
I verified that the test output of io/test was correctly written to the
streams after this change (there were no progress lines in the output).
The previous implementation of supershell log line interlacing with
regular line interlacing relied on state in a global object. A somewhat
better approach is for each appender to hold a reference to a state
object. Every time tasks run, new appenders are created, so the state
should always reflect the current progress state.
Ref https://github.com/sbt/sbt/issues/4911. This names each parallel
test task with the name of the task so that supershell can display it.
It only applies for parallel tests. When run sequentially, supershell
will still display executeTests.
Disabling supershell when color mode is disabled is a sensible default
(especially for piped output). However, I think it should still be
possible to use supershell in no color mode.
This requires a util change that also enables supershell in no color
mode.
Supershell actually works quite well in no color mode. On the sbt side,
we still want to disable supershell automatically if the output is not a
terminal or no color is set, but this commit allows the user to force
supershell through -Dsbt.supershell or the useSuperShell setting even
when no color is set.
With this commit, I improved the padding management so that padding is
now added above the progress report. Whenever a line is logged at the
info or greater level, we can reduce the padding level by one since that
line has effectively filled in the padding.
With the current supershell implementation, the progress display
flickers when there is heavy console logging during task evaluation.
This is because the console appender clears out the task progress and it
isn't restored until the next periodic super shell report (which
runs every 100ms by default). To remove the flickering, I reworked the
implementation to interlace the log lines with progress reports. In
order to ensure that the log lines remained contiguous, I had to apply
padding at the bottom of the supershell region whenever the new report
contained fewer lines than the old report. The report shifts down as new
log lines are appended. This isn't optimal, but I think removing
the flickering while preserving contiguous log lines is worth it.
It is redundant and slow to restamp all of the dependency classpath
files when they have likely already been stamped by a subproject.
For the classfiles of subprojects, we fill the managedFileStampCache
with the values returned by the zinc compile analysis product stamps.
This is why they are probably already in the managed cache and should be
up to date so long as zinc is working correctly.
I noticed that various outputFileStamps tasks were showing up in the
task timing report when I ran Test / definedTests in the main sbt project.
That task became about 400ms faster after this change.
Dmitrii Naumenko
Brice Jaglin
Ethan Atkins
eugene yokota
Josh Soref