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**
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**
When sbtn (native thin client) can't find a running sbt server, it prompts
to start one. There was no way to opt out of server auto-start from the
client side, which is needed for CI environments and scripting (sbt/sbt#7079).
**Solution**
Reuse the existing sbt.server.autostart system property in NetworkClient
to control whether sbtn should attempt to start a server. When no server is
running and sbt.server.autostart=false, sbtn exits with an error instead
of prompting.
Support setting this property via:
- sbtn --no-server compile (sets sbt.server.autostart=false)
- sbtn --autostart=false compile (new flag following sbt conventions)
- sbtn -Dsbt.server.autostart=false compile (direct system property)
- sbt --autostart=false compile (bash runner and sbtw)
This follows sbt's naming conventions for properties/options: positive
property names with =false opt-out (like --color=false, --supershell=false).
Fixessbt/sbt#7079
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
**Problem**
When you pass -sbt-dir "/Users/a' dog" on the command line, the launcher correctly produces:
-Dsbt.global.base=/Users/a' dog
But when you put the same option into .sbtopts, the launcher previously split the line on spaces without respecting quotes, so the resulting -Dsbt.global.base was truncated (for example, -Dsbt.global.base=/Users/a'). This made .sbtopts behavior inconsistent with CLI behavior and broke setups where the global sbt directory path contains spaces and an embedded quote.
Avoid launching sbt just to render --version by reading sbt.version directly from project/build.properties in the shell script, batch script, and sbtw wrapper. Tighten launcher integration assertions to verify version output no longer depends on the sbtVersion command output.
**Problem**
Running sbt 2.x with JDK 8 produces a confusing "server was not
detected" error because the JDK version check only required JDK 8+
and only ran in the non-native-client path.
**Solution**
Move java_version detection before the native client decision and add
checkJava17ForSbt2 that requires JDK 17+ when sbt major version >= 2.
Fixes#8813
* [2.x] fix: Fail early when sbt 2.x is run with JDK < 17 (sbtw)
Move JDK version check before native client decision in sbtw and
require JDK 17+ when build.properties declares sbt 2.x.
* [2.x] fix: Fail early when sbt 2.x is run with JDK < 17 (sbt.bat)
Move checkjava before native client decision in sbt.bat and require
JDK 17+ when build.properties declares sbt 2.x.
* [2.x] test: Add minimumJdkVersion helper and unit tests for sbtw
Extract JDK version check logic into Runner.minimumJdkVersion for
testability. Add RunnerSpec with tests for sbt 1.x, 2.x, and 3.x
version detection.
* [2.x] test: Bump fake java to JDK 17 for integration tests
The fake java script used by launcher integration tests reported
JDK 8. Since sbt 2.x now requires JDK 17+, the citest2 (sbt 2.x)
integration tests would fail with the new JDK version check.
* Simulate JDK 9+ rt.jar handling in fake java script
Instead of silently ignoring --rt-ext-dir (which causes sbt.bat
to mkdir on an empty string), properly simulate JDK 9+ behavior
by creating a temp directory with java9-rt-ext- prefix and a
dummy rt.jar inside it.
**Problem**
1. It's difficult to find out when Process fails.
2. global.base setting isn't needed in sbt runner script.
**Solution**
1. Forward to stderr as it happens.
2. Remove global.base setting in the runner script.
**Problem**
After PR #8730 (commit 921efce), inline comments in .jvmopts and .sbtopts files cause errors.
For example, `--add-opens=java.base/java.util=ALL-UNNAMED # comment` results in:
Error: Could not find or load main class #
The # and everything after it is now parsed as separate arguments instead of being stripped as a comment.
**Solution**
Update the sed command in outputConfigFileTokens() to strip inline comments (everything from # to end of line) before parsing tokens.
The new s/\s*\#.*// pattern matches optional whitespace + # + rest of line and removes it.
Generated-by: Claude Sonnet 4.5
**Problem**
The sbt launcher script used naive word splitting when parsing `.sbtopts` and `.jvmopts`, so arguments with spaces were split incorrectly. For example, `-J--add-modules jdk.incubator.concurrent` in `.sbtopts` and `-Dtest.key="value with spaces"` in `.jvmopts` were not passed to the JVM as intended.
**Problem**
`sbt --version` in sbt 2.x project directories was delegated to the native client, which could try to start/connect to a server instead of printing version info.
**Solution**
Skip native-client delegation when `--version` is requested, and add runner-script tests for sbt 1.x and 2.x project variants.
When in an sbt 2.x project directory, the script used to delegate to sbtn
before checking --script-version, so 'sbt --script-version' ran sbtn and
failed. Now we print the script version and exit before the native client
branch.
According to the issue, `.sbtopts` entries are appended after
CLI args in sbt 1.12.x, so `.sbtopts` JVM memory settings (e.g., `-Xmx2g`) override CLI `--mem`,
causing invalid JVM settings.
- Replace 'eval echo $line' with 'printf "%s\n" "$line"' in loadConfigFile()
- Prevents shell expansion of special characters like |, *, &, etc.
- Fixes issue where properties with pipes, wildcards, and ampersands
caused 'command not found' or 'unexpected' errors
- Add test to verify special characters are handled correctly on all platforms
Fixes#6645
The --sbt-version flag was incorrectly trying to download an sbt launcher
with the specified version, which doesn't exist for many sbt versions.
Changes:
- Modified --sbt-version handling to directly add -Dsbt.version property
- Removed sbt_version variable assignment that caused launcher mismatch
- acquire_sbt_jar now uses default launcher version instead
Now --sbt-version X.Y.Z correctly expands to -Dsbt.version=X.Y.Z without
affecting the sbt launcher version used to run the build.
eugene yokota
kenji yoshida
BrianHotopp
BitToby
Dream
PandaMan
bitloi
fireXtract
Lazz
Pluto
circlecrystalin
SID
MkDev11
Angel98518
Ondra Pelech