Since #8678 (sbt 1.12.2), Fork.apply has routed the
connectInput && outputStrategy == StdoutOutput case through a new
JProcess path that calls jpb.inheritIO(). inheritIO ties the child
JVM's stdio to the sbt server JVM's OS-level fd 1/2, bypassing the
Terminal indirection. In server mode (which sbt --client uses),
that indirection is how task output reaches the client terminal — so
the child's stdout/stderr went nowhere observable to the client.
Keep redirectInput(Redirect.INHERIT) so REPL/raw-mode keystrokes
still reach the child (preserving the use case #8678 added), but
leave stdout/stderr as PIPE and pump them to the active terminal's
output/error streams in two daemon threads. The pump threads are
joined after p.waitFor() so all buffered output drains before the
task completes.
The active terminal is captured once on the task thread rather than
re-resolved per-write via the `System.out`/`err` proxies, otherwise a
concurrent terminal swap can route mid-pump bytes to the wrong client
(observed on the CI JDK 8 matrix; the proxy's `activeTerminal.get()`
is evaluated at every write).
Forced scala/scala3 CI to downgrade from sbt 1.12.10 to 1.12.1 (see
scala/scala3#25995).
Diagnosis credit: @mbovel in #9185.
Fixessbt/sbt#9185.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
**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.
Co-authored-by: Pluto <128720033+it-education-md@users.noreply.github.com>
**Problem**
client-side run apparently won't work for Scala.JS,
so forcing sbtn users to client-side run will break the Scala.JS users.
**Solution**
This reverts the client-side run on sbt 1.x, while retaining the
mechanism for sbt 2.x usages via sbtn.
Now, if `run / connectInput := true` is true, stdout will not display on sbtn.
**Problem**
There are a few places where javaHome or java path is set,
using java.home system property. The problem is that it points to JRE,
not JDK, so it would break on Java compilation etc.
**Solution**
If the path ends with jre, go up one directory.
**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.
The BSP server didn't reset old diagnostic messages sent to BSP clients under
certain circumstances. This commit mitigates this edge case and ensures that
diagnostics for files that previously had compilation problems are properly
reset when fresh diagnostics messages are sent.
The culprit was a mismatch of map keys: Files with problems were sometimes recorded
under an absolute path, but later attempted to be retrieved by virtual path.
Fixes https://github.com/sbt/sbt/issues/6558
Problem
-------
sbt uses SecurityManager feature of JDK to trap `sys.exit` call during
`run`-like tasks, since we emulate `run` and `console` as function calls.
JDK 17 deprecated SecurityManager and it's printing warnings.
Solution
--------
About 10 years go, `exit` was a convenient way of quitting both Scala
REPL and sbt shell. Scala 2.11 broke this by removing the `Predef.exit`.
We still need to worry about `run` potentially calling `sys.exit`
but that can be handled using fork feature.
In the long-run, it probably is better to be JDK 17 compatible.
The request of the form buildTarget/* often take a sequence of build
targets as parameter. So far if there is an error on a single build
target, the entire request fails.
This is not the best because the client wants the result of the other
build targets anyway:
For example:
- workspace/buildTargets: if one build target has an invalid Scala
version we still want to import the other ones
- buildTarget/scalacOptions: if a dependency cannot be resolved we still
want to import the build targets that do not depend on it
- buildTarget/scalaMainClasses: if buildTarget does not compile we still
want the main classes of the other targets
...
The change is to respond to BSP requests with the successful
build targets and to ignore the failed ones.
This is implemented the same in Bloop since before BSP in sbt.
In https://github.com/build-server-protocol/build-server-protocol/issues/204,
I made a proposal to also add the failed build targets in the response.
The processing log is sent when a command issued by a request is being
processed, if the request has not yet been responded. In particular,
the processing log of sbtReportResult is filtered out if the client has
already received a response.
The processing log severity is the lowest so that it can be ignored by
the BSP client.
The sbt console didn't work with supershell disabled because setting
that parameter was causing the terminal type to be dumb which only works
in some very specific situations. When Terminal.isAnsiSupported was
false, we were setting sbt to use a dumb terminal. We really only want
to use a dumb terminal if virtual io is off. It also doesn't necessarily
make sense to automatically disable general ansi codes even if
supershell is disabled by system property.
The cancel on-going task with string id test was failing in CI because
of a race condition involving server log messages. We need to wait for a
notification that the project has been compiled before we wait for the
"Waiting for" message, otherwise we might pick up the "Waiting for"
message from the previous test case and try to cancel the task before it
has been created.
I was seeing some failures in travis ci where the build crashed because
it wasn't able to open a socket. This failure was happening in the
scalatest fork runner so I decided to avoid forking entirely. An
alternative approach would possibly be just to remove the scalatest
framework from the server test project but not forking is nicer anyway.
It is possible for the test cases in ClientTest to block indefinitely.
To avoid that, we can instead run them on a background thread and cancel
the thread if that happens.
BrianHotopp
eugene yokota
Friendseeker
adpi2
SlowBrainDude
unknown
xuwei-k
Matthias Kurz
Krzysztof Pado
Kamil Podsiadlo
Kamil Podsiadlo
Rikito Taniguchi
Igal Tabachnik
Jason Zaugg
Samuel CLARENC
Ethan Atkins