mirror of
https://github.com/sbt/sbt.git
synced 2026-08-31 18:24:30 +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]>
771 B
771 B
The thin client honors -java-home when it starts a server
Launcher value flags such as -java-home were parsed by the thin client but then
dropped: the = form (--java-home=/path) was forwarded to the server verbatim
and rejected as a command (Not a valid command: --), and the space form
(-java-home /path) was silently discarded when the client had to start a server,
so that server came up under the default JVM. Both forms are now consumed by the
client and re-passed to a server it starts, so the server runs under the requested
JVM, including values that contain spaces such as a Windows path
(C:\Program Files\Java\...). This also applies to the other launcher value flags
(-mem, -jvm-debug, -sbt-dir, ...), which were dropped the same way.