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
**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
**Problem**
Scripts with scalaVersion 3.x in /*** */ and a shebang fail: -Xscript is
ignored by Scala 3, and the shebang line causes "Expected a toplevel
definition".
**Solution**
- Strip shebang when copying the script so the compiler never sees it.
- For Scala 3 only: do not add -Xscript; generate Main.scala wrapping the
script body in object Main { def main(...) = { ... } }; use it as the
single source and set run/mainClass to Main.
- For Scala 2: keep existing behavior (shebang stripped, -Xscript + script
base name).
- Use Def.uncached and ScalaArtifacts.isScala3(scalaVersion.value) so
embedded scalaVersion from /*** */ is respected.
kenji yoshida
eugene yokota
BrianHotopp
Anatolii Kmetiuk
Anatolii Kmetiuk
dependabot[bot]
Dream
Daniil Sivak
ckstck
Philippus Baalman
BitToby
corevibe555
bitloi
bitloi