mirror of
https://github.com/sbt/sbt.git
synced 2026-09-01 10:37:54 +02:00
BrianHotoppandClaude Opus 4.8
380a031cc7
The thin client (sbtn) parsed the launcher value flags (-java-home, -mem, -jvm-debug, -sbt-dir, ...) but then dropped them. The space form was consumed and discarded; the flag=value form fell through to the residual arguments and was forwarded to the server verbatim, where --java-home=/path was rejected as a command (`Not a valid command: --`). When the client had to start a server (none running, no --server), the consumed -java-home never reached the forked sbt launcher, so the server came up under the default JVM and, in CI where the intended JDK is only reachable via -java-home, failed to connect. parseArgs now captures the consumed launcher value flags (both `flag value` and `flag=value`) into Arguments.launcherValueArgs, and the cold-start fork re-passes them to the sbt launcher so the server runs under the requested JVM. The client tokenizes arguments by splitting on whitespace, which would otherwise fragment a value that contains spaces (a Windows path like C:\Program Files\Java); parseArgs tracks those split boundaries and rejoins a value flag's value. An empty flag= value and a dangling flag with no value are consumed but not propagated, since the launcher's require_arg would otherwise fail the fork. The fork command construction is extracted into a pure, package-visible serverCommand so a test can assert the propagated flag reaches the started server. The sbt-launch-jar path is unchanged: it invokes java directly, with no launcher to interpret the flag. Fixes #9418 Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>