Address review feedback from eed3si9n to make it clearer that GC time
is cumulative CPU time across parallel collectors, which is why it can
exceed wall clock time.
Fixes#8002
**Problem**
consoleProject doesn't work. REPL doesn't even start.
**Solution**
I made some progress into consoleProject.
At least Scala 3.7 repl session will now start.
The problem is that compiler bridge has not implemented binding,
so we can't forward the sbt build information into the repl.
**Problems**
When running forked tests, sbt uses `Runtime.getRuntime().availableProcessors()` to determine the thread pool size, ignoring `concurrentRestrictions`. This is inconsistent with non-forked parallel tests.
**Expectations**
Users should be able to control the number of parallel test threads in forked mode, similar to how `concurrentRestrictions` works for non-forked tests.
**Notes**
Added a new setting `testForkedParallelism` that allows explicit control:
```scala
testForkedParallelism := Some(2) // Use 2 threads
testForkedParallelism := None // Use availableProcessors() (default)
```
Eviction warnings and errors were not reported for Test dependencies because
`EvictionError` only checked the Compile configuration.
This fix runs the eviction check for both Compile and Test configurations
separately, with distinct error messages:
- Compile: `found version conflict(s) in library dependencies`
- Test: `found version conflict(s) in Test dependencies`
Fixes#6645
The --sbt-version flag was incorrectly trying to download an sbt launcher
with the specified version, which doesn't exist for many sbt versions.
Changes:
- Modified --sbt-version handling to directly add -Dsbt.version property
- Removed sbt_version variable assignment that caused launcher mismatch
- acquire_sbt_jar now uses default launcher version instead
Now --sbt-version X.Y.Z correctly expands to -Dsbt.version=X.Y.Z without
affecting the sbt launcher version used to run the build.
When project loading fails in batch mode, sbt was showing an interactive
prompt asking the user to choose between retry, quit, last, or ignore.
However, in batch mode there is no interactive terminal, causing the
process to hang waiting for input that will never come.
This fix checks if we're in batch mode (Prompt.Batch) and automatically
exits with failure (equivalent to 'q' quit option) without prompting the
user. This prevents infinite retry loops on persistent errors and allows
batch mode scripts to fail fast, which is appropriate for CI/CD environments.
The interactive behavior remains unchanged for non-batch mode.
Filter rt-ext-dir output for java9-rt-ext- pattern, matching the
Unix script behavior. This prevents debug agent stdout (e.g.,
'Listening for transport dt_socket at address: 1234') from being
incorrectly parsed as a file path.
Fixes#8100
**Problem**
There's a disconnect between what is perceived to be the current
Scala version, and what sbt uses internally, and thus what it
chooses to be the default scalaVersion.
**Solution**
This displays a warning if scalaVersion setting is missing.
**Problem**
There's a disconnect between what is perceived to be the current
Scala version, and what sbt uses internally, and thus what it
chooses to be the default scalaVersion.
**Solution**
This displays a warning if scalaVersion setting is missing.
eugene yokota
MkDev11
gayanMatch
xuwei-k
calm329
calm
Angel98518
Francluob
aka James4u