The console/consoleQuick REPL loader rejects JDK platform-module
classes: ClasspathFilter's post-check refuses classes whose code
source is a jrt: URL, so a top-down REPL reference to java.sql.* falls
through to the REPL's own classloader, which finds the bytes in the
runner-generated java9-rt-ext jar (via scala.ext.dirs) and dies in
defineClass:
java.lang.SecurityException: Prohibited package name: java.sql
Wrap the REPL parent loader with a fallback that consults
ClassLoader.getPlatformClassLoader (reflectively; absent on JDK 8,
which has no platform loader) only after the existing chain misses,
so project classes keep winning and platform classes resolve instead
of being redefined. Linkage through the classpath loader (a JDBC
driver implementing java.sql.Driver) was already sound: the launcher's
topLoader delegates to the platform loader on JDK 9+; only the
top-down path through ClasspathFilter was broken.
Verified against sbt 1.11.7 (fails) and a patched 1.12.3-SNAPSHOT
(passes) with the original report's repro: java.sql.Timestamp,
a project class extending it, and DriverManager.getConnection with
the postgresql driver, which now reaches the network layer.
The console/* scripted group is added to CI; it was not in any
scripted glob, so the new test (and the pre-existing
console/project-compiler-bridge) never ran.
Fixes#4328 (still reproducible on 1.11.7 before this change).
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Add Test configuration to evictionWarningOptions
* Add Test configuration to default evictionWarningOptions
* Deduplicate eviction errors based on callers.
* Update eviction error test for semantic versioning.
* Group evictions by configuration and update test.
**Problem**
When managedScalaInstance is set to false, we stopped creating
ScalaInstance, but the documentation says the user can
pull in their own dependencies.
**Solution**
Attempt to construct a ScalaInstance from update report
even when managedScalaInstance is set to false.
**Problem**
`scalaOrganization` was ignored during compiler bridge resolution because `ZincLmUtil.getDefaultBridgeModule` hard-coded `ScalaArtifacts.Organization` (`org.scala-lang`).
**Solution**
Add a `scalaOrganization` parameter to `ZincLmUtil` methods, and passing `scalaOrganization` value to those methods.
Generated-by: Claude Opus 4.6
Co-authored-by: Rikito Taniguchi <rikiriki1238@gmail.com>
Commit 92b0564dc (fix for #8632) changed `csrSameVersions` so that Scala 2.13+ only aligned `scala-library` and `scala3-library`. This removed `scala-compiler` and `scala-reflect` from version
unification, so transitive dependencies pulling in an older `scala-compiler` (e.g. 2.13.15 via `refined_2.13`) were no longer evicted to match `scalaVersion` (e.g. 2.13.18).
**Problem**
We enforce same-version policy for scala-reflect in Scala 2.13.
However due to sandwich dependency, the graph can bump
scala-library to 3.8.1, which is missing scala-reflect counterpart.
**Solution**
Drop the same-version policy.
**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**
On IntelliJ the users are getting the hint to upgrade to -Xsource:3
style, however the supported syntax do not parse.
**Solution**
This adds -Xsource:3 to the parser. The metabuild compilation uses
-Xsource:3 since sbt 1.6.0.
**Problem**
dependency-tree currently doesn't include Provided configuration,
because technically it isn't part of the Compile configuration,
however, Provided does become part of the Compile classpath during compilation.
**Solution**
This changes the implementation to use the internal configuration,
e.g. CompileInternal, which includes the auxilary configurations.
There's a tradeoff here since it means that we lose the tree view of
the platonic Compile configuration.
**Problem**
Scala 3.8 REPL won't work since they've split the repl artifact into another JAR.
**Solution**
This works around it by creating a yet-another sandbox configuration ScalaReplTool
(similar to ScalaTool and ScalaDocTool) and a separate scalaInstance for
console task, so when Zinc is invoked we'll be able to conjure the right array of JARs.
**Problem**
Client-side run currently fails on JDK 8 because sbtn
creates args file even though JDK 8 does not support it.
This is likely because sbtn is compiled using GraalVM on a modern JDK.
**Solution**
This adds a new fork option canUseArgumentsFile to delegate the args file decision
to the server, and default to false if the value is missing.
This retroactively fixes sbt 2.x client-side run.
**Problem**
Scala 3.8.0 nightly and later in-sources the scala-library for the use by Scala 3, as opposed to using Scala-2.13-bound standard library.
This means that we will run into situations where scala-library should NOT align with scala-reflect, which might exist transitively.
**Solution**
Adjust the csrSameVersions rule for Scala 3.8 so it will only try to keep scala-library and scala3-library versions aligned.
As a consequence, this fixes artifact name contraction for maven style and thus fixes publishing to Sonatype when a cross-built sbt version is different from 1.0
**Problem**
Central Portal no longer supports the legacy sbt plugin layout.
**Solution**
Make the default more friendly by setting sbtPluginPublishLegacyMavenStyle to false.
sbt added the `sonaDeploymentName` key with https://github.com/sbt/sbt/pull/8126, released with https://github.com/sbt/sbt/releases/tag/v1.11.0 - in use, this seems to be getting lint warnings (as introduced by https://github.com/sbt/sbt/pull/5153):
```
[warn] there's a key that's not used by any other settings/tasks:
[warn]
[warn] * scala-collection-plus / sonaDeploymentName
[warn] +- /home/runner/work/scala-collection-plus/scala-collection-plus/build.sbt:3
[warn]
[warn] note: a setting might still be used by a command; to exclude a key from this `lintUnused` check
[warn] either append it to `Global / excludeLintKeys` or call .withRank(KeyRanks.Invisible) on the key
```
https://github.com/rtyley/scala-collection-plus/actions/runs/15326291872/job/43121748535#step:6:19
...https://github.com/sbt/sbt/pull/5153 does say that "notable exceptions are settings used exclusively by a command" - I _think_ that maybe `sonaDeploymentName` is only used by the commands `sonaRelease` & `sonaUpload`, so it's necessary to add it to `excludeLintKeys`?
**Problem**
1. query string wasn't passed in, so sonaRelease wasn't working
2. deployment name should be human readable
**Solution**
This fixes the query string passing by hand-crafting the URL.
This also generates human readable deployment name.
**Problem**
Sonatype is sunsetting HTTP Rest endpoint OSSRH in June 2025.
**Solution**
This implements a built-in publishing mechanism.
Kudos to David Doyle who has spearheaded Sonatype Central support via sonatype-central-client etc.
Ensures that `buildTarget/compile` returns a `StatusCode.Error` instead
of a JSON-RPC error even when the compile error is buried deeper in the
`Incomplete` causes.
Fixes#8104
**Problem**
Incremental test (aka testQuick) has a bug when companion objects
depends on others since at some point it's failing to look up relationship from Zinc analysis.
**Solution**
This fixes the lookup.
**Problem**
sbt 1.10.10 still has retry problem with compilation.
**Solution**
Revert the retry logic back to the time when we only retried IOExceptions.
**Problem**
The error message uses name, which may not match the actual project id
that the user can type into the shell.
**Solution**
Use displayBuildRelative to calculate the proper subproject id.
Anatolii Kmetiuk
BrianHotopp
Zainab Ali
eugene yokota
calm
calm329
azdrojowa123
Aleksandra Zdrojowa
xuwei-k
Hamza Remmal
JeanMarc van Leerdam
Jules Ivanic
Dmitrii Naumenko
Roberto Tyley
Alec Theriault