**Problem**
Calling -bsp with --sbt-launch-jar causes "Unrecognized option: --server".
This is because --server is passed in twice since $7775
**Solution**
Since the server invocation by BSP client already passes in --server,
we can remove the extra --server append.
In addition to ExecuteProgress, this new interface allows builds and plugins to receive events when commands start and finish, including the State before and after each command. It also makes cancellation visible to clients by making the Cancelled type top-level.
- remove unused type params
- use `withFilter` if possible
- use `collectFirst` instead of `collect` and `headOption`
- use `length` instead of `size` if `Array` or `String`
- use `foreach` instead of `map`
Problem
-------
There's a bug in ipcsocket cleanup logic that effectively
tries to wipe out /tmp.
Workaround
----------
We should fix the underlying bug, but we can start by
explicitly configuring the temp directories ipcsocket uses.
Ref https://github.com/sbt/sbt/issues/6931
The `XDG_RUNTIME_DIR` environment variable will be used to choose the base directory in which the sockets will be created by **sbt**. This can help when issues such as #6777 appear. There are other related issues, such as #6101, [Metals issue #2235](https://github.com/scalameta/metals/issues/2235), [Che issue #18394](https://github.com/eclipse/che/issues/18394). Those are closed issues, but there are some cases in which the solution does not work (such as the case in #6777). Furthermore, the solution given seems more like a workaround than an actual fix.
**What causes this issue?**
At least in my case, the **ServerAlreadyBootingException** is thrown after **sbt** tries to create a Unix domain socket and fails. In my specific environment, I was not able to create the sockets in some directories because they were mounted on an NFS. This prevented me from using any automated sbt command on any of those directories (Metals uses sbt under the hood, and it was not able to start because of the ServerAlreadyBootingException), which in turn resulted in me not being able to use Metals on a project that was created on any of those directories.
**How is the issue solved in this PR?**
If the `XDG_RUNTIME_DIR` environment variable is set, then sockets will be created in a folder with a hashed name, inside the directory `XDG_RUNTIME_DIR/.sbt/`. If this variable is not set, everything works exactly the same as always.
Let's see an example:
1. My environment variable `XDG_RUNTIME_DIR` is set to /home/alonso/.runtime-dir`
2. I create my project in `/home/alonso/workspace/hello-world`
3. I run `sbt compile`
4. The socket is created in `/home/alonso/.runtime-dir/.sbt/sbt-socket102030405060/sbt-load.sock`. The number **102030405060** is a hash that is computed from the base directory of the project (it is actually the same hash that is produced in order to create sockets in Windows) and it will be different depending on the location of the project
5. The sbt command executed correctly, which would not have happened if the socket had been created in the `home/alonso/workspace` directory or any of its subdirectories (in this example, `/home/BlackDiamond/workspace` corresponds to a network file share)
Co-authored-by: Alonso Montero <lumontero@mobilize.net>
In order to start the sbt server we must use the sbt script because
it is the only way to load the .sbtopts and the .jvmopts file properly.
To do so the sbt script can pass a -Dsbt.script prop to the java server.
It is used in the NetworkClient to start the server, and it is replicated
in the BuildServerConnection file (.bsp/sbt.json).
The problem was that -client was different from --client, which
makes for a confusing user experience. So, this change makes
them the same and re-names -client to --java-client. The value
of this is that hopefully -client and --client being the same
feels more logical to users.
The intellij bsp integration launches sbt with the launcher and runs
-bsp. This doesn't work if sbt is not on intellij's path. To try and
work around this, we can add an option --sbt-launch-jar that is
recognized by the network client and will make it use the launch jar
rather than the sbt script to launch a new server if needed.
Made the bspConfig task dependendant on the bspConfig value.
Changed the bspConfig setting to use a attributeKey so we can use it in the server as well.
The new version provides an apple silicon arm64 jni implementation of
the ipcsocket api. It also adds a jni implementation for getting the max
socket length which is necessary because jna isn't supported on the
apple arm64 platform yet.
friendseeker
Eugene Yokota
Karl Yngve Lervåg
adpi2
Matthew de Detrich
azdrojowa123
Iulian Dragos
xuwei-k
Julien Richard-Foy
Alonso Montero
dmitrii.naumenko
Philippus
David Francoeur
Samuel CLARENC
Samuel CLARENC
Amina Adewusi
Ondra Pelech
Sam Halliday
João Ferreira
Guillaume Martres
Ethan Atkins
Erlend Hamnaberg