When the download URL returns an HTTP error (e.g. 404), curl without
--fail exits 0 and saves the error page HTML as the jar file. This
leaves a corrupt jar that causes confusing errors on subsequent runs.
With --fail, curl returns a non-zero exit code on HTTP errors and
does not write the response body to the output file.
Fixes#6654
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
**problem**
.previous was implemented as an inline expansion to wrapInitTask(Previous.runtime(in)(<instance of JsonFormat[A1]))
For example, the .previous on taskKey[String] gets inlined like
this, and then sbt's macro moves `Previous.runtime(...)(using StringJsonFormat)` into task input.
lazy val fingerprints = taskKey[String]("...")
val previousFingerprints = fingerprints.previous
// inlined
val previousFingerprints: Option[String] = {
InputWrapper.wrapInitTask(
Previous.runtime(...)(using StringJsonFormat)
)
}
- 6c8ee6ea37/main-settings/src/main/scala/sbt/Def.scala (L410-L412)
- 6c8ee6ea37/core-macros/src/main/scala/sbt/internal/util/appmacro/Cont.scala (L468)
However, if the return type of task is a bit more complicated like
Seq[String], it doesn't work:
Scala 3 Compiler's inliner creates a synthetic proxy symbol if the
inlining tree is an application, whose arguments are unstable path.
For example,
lazy val fingerprints = taskKey[Seq[String]]("...")
val previousFingerprints = fingerprints.previous
// inline to
val previousFingerprints: Option[Seq[String]] = {
val x$2$proxy1 = immSeqFormat(StringJsonFormat)
InputWrapper.wrapInitTask(
Previous.runtime(...)(using x$2$proxy1)
)
}
cc7d6db700/compiler/src/dotty/tools/dotc/inlines/Inliner.scala (L324-L329)
However, sbt2's Cont macro captures only `Previous.runtime(...)(using x$2$proxy1)`, while it doesn't capture the proxy definition. Consequently, while sbt macro moves the `Previous.runtime(...)` application as a task input, the proxy definition is left in the task body.
mapN(
(
link / fingerprints,
Previous.runtime(...)(using x$2$proxy1) // here x$2$proxy1 can't be found
)
) {
...
val x$2$proxy1 = ...
}
Then we get:
-- Error: /.../build.sbt:14:59
14 | val previousFingerprints = (link / fingerprints).previous
| ^
|While expanding a macro, a reference to value x$2$proxy1 was used outside the scope where it was defined
**How this PR fixed**
This commit fixes the problem by defining a dedicated Scala3 macro for .previous that summon JsonFormat[A1] inside the macro before constructing the wrapped previous.runtime(...)(using ...) by inliner. The macro insert the found given value tree directly into the previous.runtime(...)(using $found).
This way, Cont macro always moves the Previous.runtime tree along with it's given argument, without leaking compiler-generated inline proxies across scopes.
**Problem**
Like File, Path normally captures the absolute path,
so likely not a good candidate for caching.
**Solution**
Ban it.
---------
Co-authored-by: Anatolii Kmetiuk <anatoliikmt@proton.me>
getFileProperty returned relative File objects when system properties
like sbt.global.base were set to relative paths (e.g. via -sbt-dir
../cache in .sbtopts). This caused an assertion failure in
IO.directoryURI: "Not absolute: ../cache/plugins".
Also fixes misleading scaladoc in SemanticSelector that claimed
`<=1.0` is equivalent to `<1.1.0` — they differ for pre-release
versions like 1.1.0-M1 (#4423).
Fixes#3729
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
**Problem**
When usePipelining := true in a multi-project build, sbt appends
-Ypickle-java and -Ypickle-write <path>/early.jar to scalacOptions
for fast parallel compilation. These flags were being leaked into the Scala
REPL, causing failure on console
**Solution**
Strip pipelining flags before forwarding to the REPL in Deafults.scala.
**Problem**
There seems to be multiple problems around metabuild reloading (reload plugins).
1. Originally reported issue 9006 states that the build can't come back
from reload plugins.
2. During the course of fixing, I discovered that when reload plugins is used
the project name is set to "project" instead of foo-build etc.
3. Also there was a bug in the rootPaths when reload plugins is used,
which results in class not defined error.
**Solution**
1. Fix the plugin context so reload plugin still behaves like a metabuild.
2. Fix the rootPaths.
**Problem**
When build.sbt contains no explicit project definition (e.g. just bare settings with no lazy val root = project.in(file("."))), sbt creates a synthetic root project. In Load.loadTransitive, this synthetic root was processed with expand = false, which prevented AutoPlugin.derivedProjects from being called.
Any plugin relying on derivedProjects to inject projects would fail with "Reference to undefined setting" errors.
The workaround was to add an explicit root project in build.sbt (val root = project.in(file("."))), which caused the Some(root) branch to execute with expand = true.
**Solution**
Removed the expand variable from loadTransitive and pass true directly to processProject. Previously, the Some(root) branch set expand = true while the None branch set expand = false. Since derivedProjects should always be invoked for the root project regardless of whether it was explicitly defined or auto-generated, both branches should behave the same way. Eliminating the variable makes this intent clear.
earlyOutput is a virtual file reference, so passing it directly via
.toString produces a virtual path that scalac cannot resolve. Use
fileConverter.value.toPath() to convert it to an actual filesystem path.
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* [2.x] feat: Add cacheVersion setting for global cache invalidation
**Problem**
There was no escape hatch to invalidate all task caches when needed.
**Solution**
Add `Global / cacheVersion` setting that incorporates into the cache key
hash. Changing it invalidates all caches. Defaults to reading system
property `sbt.cacheversion`, or else 0L. When 0L, the hash is identical
to the previous behavior (backward compatible).
Fixes#8992
* [2.x] refactor: Simplify BuildWideCacheConfiguration and add cacheVersion test
- Replace auxiliary constructors with default parameter values
- Add unit test verifying cacheVersion invalidates the cache
* [2.x] fix: Restore auxiliary constructors for binary compatibility
* [2.x] test: Improve cacheVersion scripted test and add release note
- Scripted test now verifies cache invalidation via a counter
that increments only when the task body actually executes
- Add release note documenting the cacheVersion setting
publishM2 never wrote maven-metadata-local.xml, which Maven uses to
distinguish local installs from remote artifacts. Without it, Maven
re-downloads remote SNAPSHOTs even when a local copy exists, making
publishM2 effectively broken for SNAPSHOT workflows.
Fixes#2053
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The first paragraph of `help ++` still said "binary compatible" from
before PR #6946 changed the behavior to use SemanticSelector pattern
matching. Update it to match the already-correct second paragraph.
Fixes#6988
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
**Problem**
When dependencyMode := Direct is set, the filtering was applied at
the managedClasspath level, which removed transitive dependencies
from all downstream classpaths including Test / dependencyClasspath.
This caused runtime test failures because transitive deps like
hamcrest-core (pulled in by junit) were missing.
**Solution**
Move the dependencyMode filtering from managedClasspath to a new
filteredDependencyClasspath task, and wire dependencyPicklePath
(the classpath used by the compiler) to use it. Runtime classpaths
like dependencyClasspath and fullClasspath remain unfiltered,
preserving all transitive dependencies for test execution.
Fixes#8989
**Problem**
When publishing with coursier, the `visibility` attribute of `<conf />`
elements in `ivy.xml` was hardcoded to `"public"`. Configurations
defined as hidden (e.g. `scala-tool`) were incorrectly published with
`visibility="public"` instead of `"private"`.
The root cause was that `Inputs.configExtendsSeq` only extracted config
names and extends relationships, discarding the `isPublic` flag from
sbt's `Configuration` objects.
**Solution**
Add a `privateConfigNames: Set[String]` field to the lmcoursier
`Project` data class (with `@since` for backward compatibility).
Populate it from `Configuration.isPublic` in `CoursierInputsTasks`,
and use it in both `IvyXml` implementations to set the correct
visibility attribute.
Fixessbt/sbt#5455
**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>