**Problem**
1. forked console is missing user code from the classpath.
2. forked console still blocks the server.
**Solution**
1. This includes proper products and classpaths to the console.
2. This also implements client-side run for console.
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**
The configuration name translation in logging was incorrect. When a
configuration like MultiJvm (id="MultiJvm", name="multi-jvm") was
displayed, it showed "Multi-jvm" instead of "MultiJvm" because the
display logic was guessing the identifier by capitalizing the ivy
config name.
**Solution**
This fix:
- Adds configNameToIdent reverse mapping in ConfigIndex to look up
the correct Configuration.id from the ivy config name
- Adds toConfigIdent method in KeyIndex trait for display lookup
- Updates Scope.display to accept a config name lookup function
- Updates showLoadingKey and showContextKey to use the index lookup
Fixes#5211
Generated-by: Claude
Implements cooperative idle server cleanup for `sbtn` (issue #8610). When a client disconnects from an sbt server, that server notifies all
other registered servers to shut down if they've been idle long enough and have no connected clients. This prevents accumulation of idle
background JVMs across projects.
fixes#8610
When an AutoPlugin adds a project at the build root via extraProjects,
avoid creating a second root from the build definition so both do not
share the same target directory. Treat extraProjects root as 'root
already defined' and exclude the build-defined root from initialProjects
when both would be at the same base.
- Add ivylessPublishMavenToFile and ivylessPublishMavenToUrl for Maven layout
- Handle MavenCache and MavenRepo in ivylessPublishTask (file + HTTP)
- Add credentialFor for realm+host credential matching per Publishing docs
- Consume HTTP response body on success to avoid connection leak
- Add scripted tests: ivyless-publish-maven, ivyless-publish-maven-http
When using the aggregated key parser, a key is now valid if it exists in `data` for that scope **or** it's an aggregate key and every key it aggregates to exists in `data`. So `(root, scripted)` is accepted when the root aggregates a project that defines `scripted`, and running `scripted` at root runs it on that project as before.
Implements ivyless publish task as part of #7639 (drop Ivy dependency).
Fixes#8639.
- Add ivylessPublish for URLRepository: HTTP PUT with optional Basic auth,
same layout as ivyless publishLocal (artifacts + ivy.xml + checksums).
- Add ivylessPublishToFile for FileRepository: write to local path for
testing without HTTP server.
- Add ivylessPublishTask: when useIvy is false, use ivyless path for
URLRepository or FileRepository; otherwise use Ivy.
- Wire publish in Defaults to LibraryManagement.ivylessPublishTask
(tagged Publish, Network).
- Add scripted test dependency-management/ivyless-publish using
Resolver.file to verify ivyless publish produces identical layout.
Credentials supported via allCredentials (Basic auth for PUT).
When a project depended on another project that was built with a different Scala binary version (e.g. 2.12 vs 2.13), compilation could fail with "not found: value X" because resolution was asking for the wrong artifact.
This change updates how we build the `ModuleID` for inter-project dependencies in `projectDependenciesTask`: we now request the dependency’s Scala binary version (e.g. `bar_2.12`) instead of the current project’s, so the resolver can find the right artifact. We keep existing behavior for `Disabled` and `Constant` cross-version, and add a small safeguard in the default case when the dependency’s Scala version differs from the current project’s.
**Consuming BOMs**
- You can declare a BOM with `.pomOnly()` and versionless deps with `"*"`:
- `libraryDependencies += ("com.fasterxml.jackson" % "jackson-bom" % "2.21.0").pomOnly()`
- `libraryDependencies += "com.fasterxml.jackson.core" % "jackson-core" % "*"`
- BOMs are passed to Coursier via `Resolve.addBom()`; version `"*"` is resolved from the BOM.
**makePom**
- POM-only dependencies are emitted under `<dependencyManagement><dependencies>...</dependencies></dependencyManagement>` with `<type>pom</type>` and `<scope>import</scope>`.
- Dependencies with version `"*"` are emitted without a `<version>` element so Maven uses the BOM-managed version.
**Ivy / publishLocal emulation**
- When publishing to Ivy (e.g. `publishLocal`), BOM-resolved versions (deps that had `"*"`) are written into the published `ivy.xml` as forced dependencies (`force="true"`), so consumers that depend on this module get those versions.
**Problem**
1. Write a scripted test that runs sbt in that test.
2. sbt writes `sbt.version` under `project/build.properties`, which acts as a test filter.
3. The test setup is implicitly altered.
**Solution**
Before writing `build.properties`, sbt checks whether the base directory is inside a scripted test directory (path contains `sbt-test`). If so, it skips writing so the test setup is not altered.
Add a rootProject convenience macro that expands to a Project with base "."
and the enclosing val name as id. Allows writing `val root = rootProject`
instead of `val root = (project in file("."))` for a stable root project id.
Resolving ThisProject to ProjectRef(uri, p.id) created a self-reference
in the aggregate (and dependency) list. BuildUtil.checkCycles runs
topological sort on this relation and throws Cyclic when it sees the
self-loop.
Treat ThisProject as no-op: resolve to Vector.empty so the build loads
without error. aggregate(ThisProject) / dependsOn(ThisProject) is
effectively a no-op (self is already included).
Fixes#3616 - Scope's resolveProjectBuild and resolveProjectRef
mishandle ThisProject.
Previously, using ThisProject in aggregate() or dependsOn() would
cause a runtime error: 'Cannot resolve ThisProject w/o the current
project'.
This change adds proper handling for ThisProject in Load.scala:
- In checkAll: Skip validation for ThisProject (refers to self)
- In resolveProjects: Resolve ThisProject to ProjectRef(uri, p.id)
Problem
When a user defines an alias with a name that matches an existing task or setting key (e.g., `alias c = compile` when a custom task `c` exists), the alias silently wins and shadows the task.
Solution
Detect conflicts at alias creation time and fail with an error message:
```
Alias 'c' conflicts with a task or setting key of the same name. Use a different alias name to avoid ambiguity.
```
**Problem**
When multiple clients connect to the same sbt server, they all share the same "current project" state. When one client switches projects with `project X`, all other clients see that change.
**Solution**
Store per-channel project cursors in State attributes. Each client maintains its own cursor that tracks which project it has selected.
In PR #8621, I added a new `keepTempDirectory` parameter to `ScriptedRun.run()` and `invoke()` methods. To suppress MiMa warnings, I added `mimaBinaryIssueFilters` for:
- `DirectMissingMethodProblem("sbt.ScriptedRun.run")`
- `DirectMissingMethodProblem("sbt.ScriptedRun.invoke")`
- `DirectMissingMethodProblem` for various internal `RunV1`, `RunV2`, `RunInParallelV1`, `RunInParallelV2` classes
However, this broke binary compatibility, which prevents sbt 1.x from calling sbt 2.x for cross-building (building sbt 2.x plugins using sbt 1.x).
Fixes#8631
**Changes:**
- Add `useIvy` setting key (defaults to `true`)
- Add `ivylessPublishLocalImpl` helper that publishes without Ivy
- Modify `publishLocal` to use ivyless publisher when `useIvy := false`
- Generate ivy.xml via `lmcoursier.IvyXml`
- Generate MD5/SHA-1 checksums for all files
- Add scripted test `dependency-management/ivyless-publish-local`
## 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**
When running scripted tests to debug sbt plugins, the temporary directories (`/private/var/folder/...`) are automatically deleted after tests complete. This makes it difficult to inspect the test state for debugging purposes, requiring workarounds like adding `$ pause` commands and manually copying directories.
**Solution**
Added a new `scriptedKeepTempDirectory` setting that allows users to preserve temporary directories after scripted tests complete. When enabled, the temporary directory path is logged so users can inspect it.
Usage:
```scala
scriptedKeepTempDirectory := true
```
Problem
When using `addCompilerPlugin((dependency) % Test)`, the compiler plugin was incorrectly added to BOTH `test:scalacOptions` AND `compile:scalacOptions`, instead of only `test:scalacOptions`.
Solution
Throw when the dependency is scoped, since we do not support this use case.
**Problem**
When `autoAPIMappings := true` is set on a Scala 3 project, running `sbt doc` emits warnings:
```
[warn] bad option '-doc-external-doc:/modules/java.base#https://docs.oracle.com/...
```
This happens because Scala 3's scaladoc doesn't recognize Scala 2's `-doc-external-doc` option.
Fixes#6652
**Solution**
- Added `Opts.doc.externalAPIScala3` that generates the Scala 3 format: `-external-mappings:regex::[scaladoc3|javadoc]::url`
- Modified `Defaults.scala` to use the appropriate method based on Scala version
- Added heuristics to detect javadoc vs scaladoc based on file/URL patterns
**What it does**
When you run `dependencyLock`, sbt generates a `deps.lock` file that captures your resolved dependencies. This file can be checked into version control to ensure reproducible builds across different machines and CI environments.
**New tasks**
- **`dependencyLock`** - Generates the lock file from the current resolution
- **`dependencyLockCheck`** - Validates the lock file is up-to-date (fails build if stale)
**How it works**
The lock file stores a hash of your declared dependencies and resolvers. When dependencies change, the hash changes, and `dependencyLockCheck` will fail until you regenerate the lock file.
If no lock file exists, `dependencyLockCheck` passes silently - this allows gradual adoption.
Add support for `"3-latest.candidate"` to automatically resolve to the latest Scala 3 RC from Maven Central.
```scala
scalaVersion := "3-latest.candidate"
```
Ref https://github.com/sbt/sbt/discussions/8590
Add SetupJavaDiscoverConfig to detect JDKs installed by GitHub's
setup-java action at paths like:
- /opt/hostedtoolcache/Java_Zulu_jdk/25.0.1-8/x64 (Linux)
- C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\11.0.29-7\x64 (Windows)
These JDKs are now available in fullJavaHomes as zulu@25.0.1,
temurin@11.0.29, etc.
Supported vendors: Zulu, Temurin, Adopt, Corretto, Liberica,
Microsoft, Semeru. Temurin-Hotspot and Adopt are normalized to
temurin.
Fixes#8582
* test: Refactor setup-java tests to use real directory structure
---------
Co-authored-by: mkdev11 <noreply@users.noreply.github.com>
When running commands like 'Test/definedTests' on multi-project builds,
the output was showing raw Vector(...) format instead of nicely formatted
per-item output.
Before:
[info] svc / Test / definedTests
[info] Vector(Test FooSpec : ..., Test BarSpec : ..., ...)
After:
[info] svc / Test / definedTests
[info] * Test FooSpec : ...
[info] * Test BarSpec : ...
The fix extends printSettings to check if values are Seq types in
the multi-project case and format each item on its own line with
a '* ' prefix, matching the single-project behavior.
**Problem**
Currently the shell delegates request tasks even when a non-existent
task like Compile / update is requested.
**Solution**
This removes the delegation, if the input key is scoped, so it will fail.
We will, however, continue to delegate on the subproject axis,
since it's useful to use Global or ThisBuild scoping.
Fixes#8356
**Problem**
When `sbtn` sends a command while another long-running task (like `console`) is already executing, the client silently blocks with no indication that the command is waiting in a queue.
**Solution**
When a new command arrives via the network channel and another command is currently running, the server now sends an `ExecStatusEvent` notification with status `"Queued"` to the client. The client displays a message like:
```
[info] waiting for: console
```
**Problem**
When binary compatibility eviction errors occur, users cannot run
`dependencyTree` to debug the dependency conflict because it fails
with the same eviction error.
**Solution**
Set `evictionErrorLevel` and `assumedEvictionErrorLevel` to `Level.Warn`
for the `dependencyTreeIgnoreMissingUpdate` task, allowing the dependency
tree to be displayed even when eviction errors are present.
Fixes#7255
When using fork := true, sbt spawns child processes that may become
stale if cancelled. Previously, these processes were not cleaned up
when running the exit command.
This fix adds RunningProcesses.killAll() to the shutdown hook so that
all tracked forked processes are terminated when sbt exits.
Fixes#7468
Fixes#7481
When sbt is started by a remote client (BSP or thin client via --server flag),
always start the server regardless of autoStartServer setting. The autoStartServer
setting is meant for automatic server startup, not for blocking explicit server
start requests.
Fixes#7489
When using nested task scopes like otherTask / testTask, the
inputFileChanges macro was returning the wrong scope. It checked
if the scope already had a task axis and returned it as-is, but
this meant it would use otherTask's scope instead of testTask's.
The fix always sets the task axis to the key being queried,
ensuring fileInputs settings are found at the correct scope.
When watchTriggers is explicitly set (non-empty), use only watchTriggers
instead of combining them with fileInputs. This allows users to control
what triggers the watch by setting watchTriggers.
Fixes#7130
When sbt.version in build.properties has trailing whitespace,
sbt incorrectly reports a version mismatch even after reboot.
This fix trims the property value in all places where sbt.version
is read from build.properties:
- Main.scala (version mismatch warning)
- MainLoop.scala (clean command version detection)
- ScriptedTests.scala (test compatibility check)
Fixes#8103
**Problem**
When a val definition in build.sbt changes and the user runs `reload`, sbt crashes with `NoClassDefFoundError: $Wrap<hash>$`.
```
java.lang.NoClassDefFoundError: $Wrape8743d4f36$
at $Wrap0b8ea34d40$.$anonfun$1(build.sbt:1)
```
The workaround was to delete `project/target` directory.
**Solution**
The root cause was that imports were not included in the hash calculation when evaluating build.sbt expressions. When a val definition changes:
1. Its `$Wrap` module gets a new hash
2. Settings that reference the val get new imports pointing to the new module
3. But if the setting expression didn't change, its hash was the same
4. The old cached class was loaded with bytecode referencing the old module
Fix: Include imports in the hash calculation in `Eval.evalCommon`. Also re-enable `cleanEvalClasses` in `Load.scala` which was disabled pending this fix.
Filters out empty versions during parser construction to prevent RuntimeException when creating token parsers. Includes comprehensive test coverage for edge cases.
DependencyTreePlugin is an AutoPlugin with trigger = AllRequirements,
so it loads automatically in scripted tests without requiring explicit
plugin configuration.
Fixes#7511
The previous check used contains("scala-library") which incorrectly
matched any jar with that substring anywhere in the filename, causing
user libraries named like "my-scala-library-foo" to be misclassified
as the Scala standard library and filtered from the classpath.
Changed to use exact match (scala-library.jar) or prefix match
(scala-library-*) to only match the actual Scala library jars,
consistent with how scala-reflect is detected on line 199.
Scala 2.x has supported pipelining since 2020. The fix now allows:
- All Scala 2.x versions (pipelining supported)
- Scala 3.5.0+ (pipelining added in 3.5)
Generated-by: AI-assisted
* Add JSON output support to dependencyLicenseInfo
- Add LicenseInfo rendering object with text and JSON output
- Add dependencyLicenseInfo input task key
- Implement dependencyLicenseInfo task with JSON format support
- Supports --out option for file output
- Auto-detects JSON format from .json file extension
- Follows same pattern as dependencyTree task
Resolves#7771
When using '++version project/task', the parser now accepts project/command
patterns (e.g., 'docs/docusaurusPublishGhpages') even if the project doesn't
exist in the current state. This is achieved by adding a fallback parser
that accepts any 'project/command' pattern alongside the combinedParser.
Previously, '++2.12.19 docs/task' would fail with 'Project not found' if
'docs' project wasn't available in the current Scala version, but
'++2.12.19; docs/task' worked. Now both syntaxes work correctly.
The fix is targeted to only accept slash-delimited patterns, avoiding
interference with other parser components like the -v verbose flag.
Fixes#7574
This adds a new setting that allows users to
configure Coursier's FileCache to cache local file:// artifacts. When enabled,
artifacts from local repositories are copied to the cache directory, which is
useful for scenarios like bundling compiler artifacts in a local repo for
offline use.
Fixes#7547
**Problem**
When cross-building sbt plugins with explicit `scalaVersion` set in `build.sbt`, the `updateSbtClassifiers` task fails because it uses the launcher's Scala version instead of the appropriate Scala version for the target sbt version.
For example, with this configuration:
```scala
lazy val root = (project in file("."))
.enablePlugins(SbtPlugin)
.settings(
scalaVersion := "2.10.7", // Explicit for IDE support
crossSbtVersions := Seq("0.13.17", "1.0.0"),
)
```
Running sbt "show updateSbtClassifiers" would fail with:
Error downloading org.scala-sbt:scripted-plugin_2.12:0.13.17
It should look for scripted-plugin_2.10:0.13.17 since sbt 0.13.x uses Scala 2.10.
**Solution**
Modified sbtClassifiersTasks in Defaults.scala to:
1. Check if the project is an sbt plugin (sbtPlugin.value)
2. For plugins, derive the Scala version from pluginCrossBuild / sbtBinaryVersion using PluginCross.scalaVersionFromSbtBinaryVersion
3. For non-plugins, continue using the launcher's Scala version (original behavior)
**Problem**
When project A's dependencies changed and A was compiled in one command, project B (depending on A) would not invalidate its update cache in a subsequent command. This caused stale classpaths.
The root cause was that `depsUpdated` only checked `!stats.cached`, which only detected fresh resolves within the same command. When a dependency was served from cache (even if resolved fresh in a previous command), `cached` was marked `true`, causing incorrect cache reuse.
Debug scenario from issue:
sbt:aaa> clean
sbt:aaa> a/compile
sbt:aaa> show itTests/depsUpdated
[info] * false <-- BUG: should be true
**Solution**
Added `stamp: String` field to `UpdateStats` that records when the update was resolved. This stamp persists across commands and enables accurate cross-command comparison:
- If any dependency's stamp > our cached stamp, we re-resolve
- Falls back to `!cached` check for backwards compatibility with old caches
- Using `String` type allows future transition from timestamps to content hashes
Set window title to 'sbt <command>: <org> % <name> % <version>' when
running sbt run, runMain, bgRun, or bgRunMain.
For server-side runs, window title is set directly. For client-side runs (sbtn), window title is passed via RunInfo protocol
and set by NetworkClient.
Fixes#7586
When Java compiler generates warnings about missing annotations from
JAR files, the path format is jar:file:///C:/... which causes
InvalidPathException on Windows due to the : character.
The fix filters out jar: paths in toDocument(), similar to how fake
positions like <macro> are already filtered out. This prevents the
exception and allows compilation to continue.
Diagnostics for files inside JARs are not shown in the IDE, which is
correct behavior since they cannot be edited.
Fixes#7665
Generated-by: Cascade (AI pair programmer)
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`
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.
**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.
**Problem**
sbt 2.x uses crossTarget by default, but it contains Scala version
even when crossPaths is false.
**Solution**
This replaces it with the letter "u" for unspecified.
Preserve original direct dependencies (plugins) and merge with transitive dependencies
Original dependencies may include plugins that are NOT transitive dependencies of sbt
**Problem**
Compiler bridge resolution calls out to Coursier,
and it shows up on the profiler.
**Solution**
This uses sbt 2.x caching to cache the prebuilt compiler bridge binaries
to avoid calling Coursier from second time onwards.
**Problem**
During the milestone releases of Scala, e.g. Scala 2.13.0-M1,
scalaBinaryVersion by design points to 2.13.0-M1,
and also the source directory uses scala-2.13.0-M1,
but in most cases we actually want to pretend compatibility
and use scala-2.13 directory.
**Solution**
This introduces a new setting called scalaEarlyVersion,
which is the scalaBinaryVersion of the release version of milestones.
We have been calling this "partial version", but that broke
down for Scala 3, which adopted semantic versioning.
**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**
Protobuf reading shows up as one of the bottlenecks during no-op compilation.
**Solution**
This adds a local, in-memory cache of Zinc Analysis using the timestamp
and the file size of the persisted protobuf file.
**Problem**
sha256 is currently a bottleneck for no-op compilation.
**Solution**
This adds a local, in-memory cache of sha256 hashes of binary files
using their timestamp and file size.
The size of the digest cache can be configured using localDigestCacheByteSize,
which is set to 1MB by default.
**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**
For sbt 1.x, the user is forced to pick between having a stable ID for the root project,
or having the automatic aggregation of all subprojects.
The problem becomes more pronounced for large build that frequent add/remove subprojects.
**Solution**
This implements `.autoAggregate` method on `Project`, which is implemented as
`this.aggregate(LocalAggregate)`.
At the loading time, we can automatically expand `LocalAggregate` to a list of subproject references,
after we discover all subprojects.
The `autoAggregate` will use the base directory of the subproject to pick the parent-child
relationship. For example, a root project would aggregate all subprojects,
but `bar` might aggregate only `bar/bar1` and `bar/bar2`.
**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**
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.
Eugene Yokota
calm
bitloi
bitloi
MkDev11
azdrojowa123
byteforge
E.G
Pegasus
MkDev11
SID
Satoshi Dev
kenji yoshida
Match
Dairus
SalesforcePeak
Saber
calm329
Francluob
aka James4u
Aleksandra Zdrojowa
Anatolii Kmetiuk
Hamza Remmal
Billy Autrey
JeanMarc van Leerdam