**Problem**
In sbt 2.x, if we execute a run task from the shell,
and if the program fails, it ends up taking down the entire shell
because client-side run rethrows, which is not desirable
for the sbt shell.
**Solution**
1. Omit printing out success for ClientJobParams, which is the runinfo.
2. Print out success or error on the client-side for shell usage case.
The fallback ServerHandler silently dropped requests with unknown
methods, violating the JSON-RPC spec. Clients like Metals that send
unrecognized requests would never receive a response, potentially
causing timeouts or hangs.
Return a -32601 (Method not found) error response instead.
---------
Co-authored-by: Claude Opus 4.6 (1M context) <[email protected]>
* [2.x] feat: Add cacheVersion setting for global cache invalidation
**Problem**
There was no escape hatch to invalidate all task caches when needed.
**Solution**
Add `Global / cacheVersion` setting that incorporates into the cache key
hash. Changing it invalidates all caches. Defaults to reading system
property `sbt.cacheversion`, or else 0L. When 0L, the hash is identical
to the previous behavior (backward compatible).
Fixes#8992
* [2.x] refactor: Simplify BuildWideCacheConfiguration and add cacheVersion test
- Replace auxiliary constructors with default parameter values
- Add unit test verifying cacheVersion invalidates the cache
* [2.x] fix: Restore auxiliary constructors for binary compatibility
* [2.x] test: Improve cacheVersion scripted test and add release note
- Scripted test now verifies cache invalidation via a counter
that increments only when the task body actually executes
- Add release note documenting the cacheVersion setting
**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 <[email protected]>
The bash launcher's runNativeClient() passed all original CLI args to
sbtn, only stripping --client. This caused sbtn to receive launcher
flags like -mem 10000, which NetworkClient.parseArgs() misclassified:
-mem went to sbtArguments and 10000 went to commandArgs, resulting in
a broken server start command.
**Problem**
When the sbt server fails to start (e.g. wrong JDK version), the client
only shows "failed to connect to server" hiding the actual error. The
server stderr is redirected to /dev/null to prevent Linux pipe buffer
deadlocks (#8442), so diagnostic output is lost.
**Solution**
Redirect server stderr to a temp file instead of /dev/null. When the
server fails to start (portfile never appears), read and print the temp
file contents before throwing ServerFailedException. The temp file is
cleaned up eagerly on both success and failure paths.
Fixes#8812
Closes#4399
- Add subscribeToAll to InitializeOption (protocol); default true for backward compatibility.
- CommandExchange: send broadcast notifyEvent/logMessage only to channels with subscribeToAll.
- TestServer: support subscribeToAll parameter for tests; AbstractServerTest: subscribeToAllForTest.
- ClientSubscriptionTest: assert default client receives build/logMessage when command runs.
- Scripted test server/client-subscription: run show name to exercise server client path.
**Problem**
Forked console currently pulls in full Zinc, which includes JLine.
**Solution**
This implements a lighter-weight, full Java ForkConsoleMain,
which no longer depends on JLine.
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.
```
Migrate the following test files from ScalaTest's AnyFlatSpec to
verify.BasicTestSuite, following the pattern established by other
test files in the sbt codebase:
- SizeParserSpec.scala (util-complete)
- MultiParserSpec.scala (main-command)
Changes in all files:
- Replace AnyFlatSpec class with BasicTestSuite object
- Convert 'should ... in' syntax to 'test(...)' syntax
- Use Scala 3 syntax with colon indentation
- Add 'end' markers
- Add explicit types where needed
Related to the ongoing test migration effort.
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
```
Fixes#8538
The code was calling e.getMessage.contains() without checking if getMessage()
returns null. Changed to use Option(e.getMessage).exists() to safely handle
null values.
** Problem **
The sbtn (sbt thin client) native image on Linux currently depends on glibc because ipcsocket uses JNI for Unix domain sockets. When building with musl for static linking, the JNI library fails to load since musl doesn't support `dlopen`.
** Solution **
Instead of upgrading to ipcsocket 2.x (which isn't ready for production), I created a `UnixDomainSocketFactory` that detects JDK 17+ at runtime and uses the native `java.net.UnixDomainSocketAddress` API directly via reflection. This completely bypasses JNI on modern JDKs.
For older JDKs (8 and 11), the factory falls back to ipcsocket 1.6.3, which is stable and well-tested.
** How It Works **
The factory checks at startup whether `java.net.UnixDomainSocketAddress` is available:
- **JDK 17+**: Uses native NIO Unix domain sockets (no JNI, no native libraries)
- **JDK 8/11**: Falls back to ipcsocket's JNI-based implementation
This approach:
- Enables musl static linking on JDK 17+ without any native dependencies
- Maintains full backward compatibility with older JDKs
- Keeps the stable ipcsocket 1.6.3 instead of the unstable 2.x
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
Previously, some additional code was used to parse the arguments to the
`help` command and ensure that the remaining commands were consistent
with the desired state of sbt.
While this code worked well in sbt 1.x, and was helpful in getting `sbt
help new` to work as expected, this does not work in sbt 2, and is
actually not required.
This patch removes the additional code, which fixes the `help` command
in sbt.
**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**
`run` task has been emulated via function call inside of a sandboxed classloader,
and blocking the command processing of sbt server loop.
This poses isolation and availability issues.
**Solution**
This implements client-side run where the server creates a sandbox environment, and sends the information to the client,
and the client forks a new JVM to perform the run.
The client-side behavior has been implemented in sbtn side already.
**Problem**
WHen portfile is not found, sbtn will try to start the server
even when the desired command is shutdown.
**Solution**
When the command is just shutdown, don't start the server.
**Problem**
`run` task blocks the server, but during the run the server is just
waiting for the built program to finish.
**Solution**
This implements client-side run where the server creates a sandbox
environment, and sends the information to the client,
and the client forks a new JVM to perform the run.
**Problem**
The sbtn response handling code is relatively stragightforward,
but it's a bit messy.
**Solution**
This cleans it up a bit, similar to the style used by Unfiltered
back then (not sure how Unfiltered plans are written nowadays) by
expressing each event handling as a partial function, and composing them
together using `orElse`.
bitloi
eugene yokota
BrianHotoppandClaude Opus 4.6
Dream
Daniil Sivak
BitToby
kenji yoshida
chrisrock1124
Eve
E.G
aka James4u
MkDev11
Match
calm329
Martin Duhem
Josh Soref
friendseeker