mirror of https://github.com/sbt/sbt.git
3f6fd595ff
Building on #9270 (which parallelized resolution in non-interactive runs by narrowing the lm-coursier lock to only fire while coursier renders its interactive progress bar), this makes `update` resolve in parallel under the interactive super shell as well. Under the super shell, LMCoursier.coursierLoggerTask previously returned None, so coursier drew its own per-module progress bars and resolution stayed serialized (those bars are not safe to render concurrently). It now supplies a CacheLogger, which both suppresses coursier's bars and flips #9270's progressBarActive predicate to false, so resolution runs in parallel. Progress is rendered at the sbt task level instead. Resolution progress is tracked by a per-command ResolutionProgress instance, created in MainLoop.next alongside Keys.taskProgress and held under an AttributeKey with the same lifecycle -- no JVM-global state. coursierLoggerTask reads it from State and hands it to the ResolutionProgressLogger that coursier's download threads call; TaskProgress holds the same instance and appends a single aggregate line at render time, e.g. "Updating 18 modules, 240 artifacts, 31.0 MiB". The instance is born empty per command and discarded with it, so totals never leak across commands and the count never resets mid-update (a single update runs a resolve phase and a separate artifacts phase). v1 renders one aggregate line because it needs no schema change; per-module status lines (which would add a status field to ProgressItem) are a follow-up. UpdateRun's report-building lock is left as a separate follow-up since the network-heavy paths (ResolutionRun/ArtifactsRun) are already unlocked. re: #5627 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| src | ||
| NOTICE | ||