**Problem**
managedScalaInstance := false fails Java-only tests because
the test runner is based on a Scala Runner and sbt 2.x
currently derives the ScalaInstance only from update.
**Solution**
For the purpose of Java-only testing, create a dummy Scala Instance.
**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.
**Problem**
While sbt-dependency-graph is useful, not just for the basic ASCII graph,
but for DOT file generation etc, it adds a large number of settings and
tasks for combination of formats and actions to the point that
we actually disable most of them by default.
**Solution*
I've had an idea for a while that dependencyTree can be implemented
as a inputTask that accepts its own subcommands and options,
and this implements that.
For example, to open the browser that hosts a DOT file, now you can write
dependencyTree dot --browse
**Problem**
test task is typed to unit.
To distinguish test from any other tasks, we want to actually type this to something.
**Solution**
Forward TestResult to the test task.
This flips the default `:=` operation to the cached task.
To opt out of the cache, use `Def.uncached(...)` or
mark the key with `@cacheLevel(include = Array.empty)`
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`?
It's sometimes useful to get the output of the macro-generated code.
This adds a mechanism to allow plugins.sbt to pass in scalacOptions,
which we can later check from the macro.
1. -Xmacro-settings:sbt:Vprint prints out the code.
2. Adding -Xmacro-settings:sbt:print-tree-structure prints out the tree structure.
**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**
Compiler options for the compiler plugins ends up capturing the absolute path, specific to the machine.
**Solution**
This encodes the plugin paths as virtual paths.
**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**
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.
**Problem**
`run` task has been emulated via function call inside of a sandboxed classloader,
and blocking the command processing of sbt server loop.
This poses isolation and availability issues.
**Solution**
This implements client-side run where the server creates a sandbox environment, and sends the information to the client,
and the client forks a new JVM to perform the run.
The client-side behavior has been implemented in sbtn side already.
**Problem**
When compilation fails, it's retrying 10 times
since Retry now retries on non-IOExceptions.
**Solution**
This adds CompileFailed to excluded exception list.
**Problem**
client-side run apparently won't work for Scala.JS,
so forcing sbtn users to client-side run will break the Scala.JS users.
**Solution**
This reverts the client-side run on sbt 1.x, while retaining the
mechanism for sbt 2.x usages via sbtn.
Now, if `run / connectInput := true` is true, stdout will not display on sbtn.
**Problem**
There are a few places where javaHome or java path is set,
using java.home system property. The problem is that it points to JRE,
not JDK, so it would break on Java compilation etc.
**Solution**
If the path ends with jre, go up one directory.
**Problem**
`run` task blocks the server, but during the run the server is just
waiting for the built program to finish.
**Solution**
This implements client-side run where the server creates a sandbox
environment, and sends the information to the client,
and the client forks a new JVM to perform the run.
**Problem**
semanticdbEnabled doesn't work on sbt 2.x
1. classes directory has changed during compilation
2. semanticdb scalacOptions are duplicated for Test
**Solution**
1. change to using the backend directory
2. reimplement scalacOptions handling
In `classifiersModuleTask` we now don't include the full plugin classpath, but include only the dependency classpath (effectively excluding sbt.PluginData.definitionClasspath). Only items from the dependency classpath are considered to be published. Only for them we can download classifier artifacts later in the `updateSbtClassifiers` pipeline.
This also fixes integration test "dependency-management/update-sbt-classifiers".
I also made the test stricter, it now tests the module ids that are included in the sbt classpath.
**Problem**
We changed the content of Chrome tracing file incorrectly
and renamed tid to tname.
**Solution**
1. This renames tname back to to tid.
2. To retain the fix to avoid Thread#getId, this calls
either the JDK 8 way or the JDK 19 way reflectively.
Add a `allowUnsafeScalaLibUpgrade` setting (default is `false`) to
demote the SIP-51 build failure to a warning.
If the scalaVersion is 2.13.12 but some dependency pulls in
scala-library 2.13.13, the compiler will stay at 2.13.12, but
the dependency classpath will contain scala-library 2.13.13.
This usually works, the compiler can run fine with a newer
scala-library on its dependency classpath.
Macro expansion may fail, if the macro uses some library
class / method that doesn't exist in the old version.
The macro itself is loaded from the dependency classpath
into the class loader running the compiler, where the older
Scala library is on the runtime classpath.
Using the Scala REPL in sbt may also fail in a similar fashion.
**Problem**
Currently sbtn doesn't correctly display the stdout
during `run` because by the time it starts the terminal has been reset.
**Solution**
Don't reset the terminal in-between the tasks.
Eugene Yokota
xuwei-k
JeanMarc van Leerdam
Jules Ivanic
Dmitrii Naumenko
Roberto Tyley
Alec Theriault
Brice Jaglin
Adrien Piquerez
Josh Soref
Lukas Rytz
Derek Wickern