**Problem**
When a scripted test creates a symbolic link within the test directory
pointing to a file or directory outside of it, the batch cleanup code
follows the symlink and deletes the external target. This is because
`view.list(base / **, !keep)` recursively traverses symlinked
directories, and the resulting paths resolve to the external location.
**Solution**
Replace the flat recursive glob listing with manual recursion that
checks `FileAttributes.isSymbolicLink` before descending into
directories, matching the pattern already used in `Clean.scala`.
Symlinks are now deleted as leaf nodes without traversing their targets.
Also hoists the cleanup helpers out of the per-test loop since they
only depend on the (constant) temp directory.
Fixessbt/sbt#7331
When multiple tasks run in parallel, the super shell progress lines reorder in a semi-random manner on every refresh because they are sorted by raw elapsed microseconds. Tasks that start at nearly the same time constantly swap positions due to sub-second timing jitter, making the display hard to read.
This fixes the sort key to use elapsed seconds (rounded down) with task name as a tiebreaker, matching the granularity already shown to the user (e.g. 3s). Tasks displaying the same elapsed second now stay alphabetically stable instead of flickering.
**Problem**
ProjectMatrix.baseSettings computes sourceDirectory and unmanagedBase using base.getAbsoluteFile, which resolves relative paths against the JVM's working directory. This works fine within a single build, but breaks for source dependencies - when an external build loaded via ProjectRef(file("ext/lib"), "lib") uses projectMatrix.in(file(".")), the file(".") resolves to the root project's directory instead of ext/lib/.
As a result, the matrix project picks up wrong sources and compilation fails.
**Solution**
Replace base.getAbsoluteFile with IO.resolve((ThisBuild / baseDirectory).value, base). Since ThisBuild / baseDirectory is set per build unit during loading, this correctly resolves against each build's own root directory.
sourceDirectory and unmanagedBase now derive from the resolved projectMatrixBaseDirectory setting.
PomGenerator never emitted <type> for dependencies with explicit
artifacts, so a WAR dependency would appear in the POM without
<type>war</type>. Maven then treats it as a JAR dependency, resolving
the wrong artifact.
Uses the primary (non-classifier) artifact to determine the type,
so .withSources()/.withJavadoc() classifier artifacts don't produce
spurious <type>doc</type> or <type>src</type> elements.
Fixes#1979
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Harden Windows VCS URI fragments against command injection
- Use Process(argv) for git/hg/svn without cmd /c on Windows
- Add VcsUriFragment.validate for fragments in clone/checkout/update
- Add tests
* Allowlist-based approach to VCS string sanitization
**Problem**
sbt always includes all transitive dependencies on the classpath.
This makes it easy to accidentally depend on transitive dependencies
without declaring them, leading to fragile builds that break when
a library changes its own dependencies.
**Solution**
Add a `dependencyMode` setting with three modes:
- DependencyMode.Transitive (default) — current behavior, all
transitive dependencies on the classpath
- DependencyMode.Direct — only declared dependencies plus
scala-library on the classpath
- DependencyMode.PlusOne — declared dependencies plus their
immediate transitive dependencies plus scala-library
Fixessbt/sbt#8942
Problem
libraryDependencySchemes didn't work for platforms like Scala.JS
Solution
Modified EvictionError.scala to extract the suffix.
Changed from _: Binary to b: Binary and added ${b.suffix} to the module name.
---------
Co-authored-by: oolokioo7 <loki021107@gmail.com>
Fixes#1144
The compileTimeOnly message on wrapInitInputTask said "`value` can
only be called on an input task..." when the user called `.evaluated`,
not `.value`. Changed to say `evaluated` and suggest `.toTask(" <args>").value`
as an alternative.
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
**Problem**
sbt bspConfig writes the absolute path of the current Java binary into .bsp/sbt.json. When the user switches Java versions (via sdkman, cs java, etc.) or removes that JDK, the IDE fails to start the sbt BSP server because the hardcoded path is stale or gone.
**Solution**
When an sbt launcher script is available (via `sbt.script` system property or PATH lookup), generate:
"argv": ["/path/to/sbt", "bsp"]
**Problem**
Coursier graph.Conflict -> DependencyTree relocation can loop forever when
Maven/Gradle relocation metadata forms a cycle (sbt-site 1.4.1).
**Solution**
Detect relocation cycles with the same step logic as Coursier, skip Conflict
for affected configs, log once per update.
Generated-by: Claude
**Problem**
set every silently discards scope axes the user provides. Running:
set every Test / sources := Nil
empties sources in **all** scopes including Compile, not just Test. This happens because rescope in SettingCompletions.setAll strips the scope and forces Global.
**Solution**
Changed rescope to keep the user's config/task/extra axes and only wildcard the project axis. When no scope is given, behavior is unchanged - all axes match everything as before.
**Problem**
When scalaVersion is Scala 3.x and a dependency brings a newer
scala3-library_3, sbt did not report an eviction error or warning.
The compiler could be older than the standard library on the
classpath, breaking compile-time alignment (e.g. scala/scala3#25406).
**Solution**
- In Compiler.scala, add an else if ScalaArtifacts.isScala3(sv) branch
in scalaInstanceConfigFromUpdate that finds scala3-library_* on the
Compile report and, if scalaVersion < that revision, fails (or warns
when allowUnsafeScalaLibUpgrade := true) with the same pattern as
the existing Scala 2.13 check (PR 7480). Message uses compile-time
alignment wording and "See evicted to know why ... was upgraded from".
- Set allowUnsafeScalaLibUpgrade := true on b3 in stdlib-unfreeze so
existing b3/run and b3/checkScala still pass.
- Add scripted tests: stdlib-unfreeze-scala3-eviction (expect compile
to fail) and stdlib-unfreeze-scala3-warn (expect success with warning).
Closes#6694