a893b1c86d
`update` held a process-global lock around coursier resolution and artifact fetching whenever a logger was set OR coursier was not in fallback mode. That lock exists only to serialize coursier's interactive progress bar, which is rendered solely when no custom logger is supplied and coursier is not in fallback mode. The `loggerOpt.nonEmpty` clause therefore over-serialized the common non-interactive case (IntelliJ re-imports, CI, any non-TTY run, where sbt supplies a quiet debug-only logger), making `update` scale with the number of modules rather than the number of distinct artifacts. Narrow the predicate to `!hasCustomLogger && !fallbackMode` (Lock.progressBarActive), so resolution runs in parallel unless coursier is actually drawing its progress bar. Interactive terminals stay serialized; COURSIER_PROGRESS=false opts into parallelism there, and #5627 tracks fully parallel resolution with live progress bars. Safe: SbtCoursierCache is ConcurrentHashMap-backed, a CacheLogger is already invoked concurrently within a single resolution (parallel downloads), and the COURSIER_PROGRESS=false parallel path has been used in production for years. Fixes #5508. Co-authored-by: Brian Hotopp <[email protected]> Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
1.1 KiB
update resolves modules in parallel
Dependency resolution (update) no longer holds a process-global lock while
coursier is not rendering its interactive progress bar -- that is, whenever a
custom csrLogger is set, or coursier is in fallback display mode (the default
under IntelliJ, CI, and any non-TTY environment, or with COURSIER_PROGRESS=false).
Previously the lock was taken even for sbt's quiet default logger, so update
processed one module at a time and its duration grew with the number of modules
rather than the number of distinct artifacts. Large multi-module builds and
IDE/CI re-imports could spend minutes serializing resolution.
The lock is still held while coursier draws its live per-module progress bars in
an interactive terminal, because that renderer is not safe to drive concurrently;
to parallelize there as well, run with COURSIER_PROGRESS=false. Fully parallel
resolution with live progress bars is tracked by #5627.
This addresses #5508.