Ability to start sbt session before Metals connects using sbt -bsp

[eed3si9n]

Is your feature request related to a problem? Please describe.

1. Open VS Code in a directory where I would like Metals to connect to sbt server.
2. If there's been previous session there will be .bsp/sbt.json.
3. Metals would then try to issue java -cp sbt-launch.jar xsbt.boot.Boot -bsp, which is sbt running in client mode.
4. When sbt -bsp does not find a running sbt session it will try to spawn sbt (server) in the background, which will take time and timeout.
5. Repeat to step 3 a few times.
6. To avoid this I'd delete .bsp/sbt.json but that doesn't feel right either.

Describe the solution you'd like

In addition to sbt -bsp, I would like a mechanism to suggest to Metals to open up a new terminal window and start a new sbt session by typing in "sbt", and wait for the server to come up. (The code exists here - https://github.com/sbt/sbt/blob/e323f1f713251968b3d4ecda8a7f0ed52593713a/vscode-sbt-scala/client/src/extension.ts#L34-L45)

Describe alternatives you've considered

Or maybe some hardcoded solution like a preference that starts sbt when sbt version is above 1.4.0-M1?

This could be convenient for testing etc purpose even if the user doesn't want to use sbt server as the build server.

Additional context

Search terms:

[tgodzik]

Thanks for reporting! I think we could ask an additional question whether you would like to start a bsp session when an sbt build is detected. Though, I am not sure how best to run the terminal, which would work in all the possible editors 🤔

[adpi2]

I think we could ask an additional question whether you would like to start a bsp session when an sbt build is detected

I think it is a good idea!

I would like to have something like:

• Metals checks if the bsp/sbt.file exists
• If so it asks if you want to connect to sbt (or if you prefer to import the build using Bloop) or not.

The good thing is that it lets you the opportunity to start the sbt shell by yourself inside Metals before clicking that you want Metals to connect to sbt.

• Then Metals can check if the target/active.json file exists
• If not it starts the sbt shell and then connect to it, else it connects to the existing sbt server.

It may seem a bit convoluted but it is the best user experience I can think of because it handles all the case I have personally experienced:

• start sbt then open vscode
• open vscode then start sbt in vscode terminal
• open vscode but dont start sbt (by myself)
• open vscode then use Bloop server even if BSP is supported by sbt

[ckipp01]

I'm going to hijack this a bit, and then make follow-up tickets more than likely in the extension repos for actually opening sbt in another tab/window/etc depending on the client. However, I think this ticket is an important part of #2049 and I'm already hitting on it a bit as I'm working through it.

One of the potential "flows" from #2049 is the the following:

1. User clones a new sbt repo
2. User open up the repo in the editor of their choice
3. No .bsp/sbt.json exists yet.
4. Then what???

Again following up on the conversation in #2049, but limiting it only to the scenario above, I'm introducing a new server command (name is flexible), build-server-start, which allows for a single param of the build server that metals may know how to start. When this lands, it will just be sbt and bloop. However, I'm trying to keep things as built-tool agnostic as possible because before too long we may be having similar conversation about how to treat mill as a build server. The temporary plan with this new command as we smooth everything out is the following:

1. User clones a new sbt repo
2. User open up the repo in the editor of their choice
3. No .bsp/sbt.json exists yet.
4. User prompted to import build...
   A. Chooses to import build, which utilizes bloop and the normal behavior up to this point happens
   B. Uses ignores the prompt
   1. Then issues a build-server-start command with the single argument sbt. This is the server command, but the client will control how it looks to user. For example in coc-metals right now I have a start-sbt-bsp-server command which just sends in build-server-start sbt.
   2. This copies over a plugin to the project/ dir, and then starts the sbt server.
      a. Right now the way I have it is then I just build-connect, but I'll probably change this to auto-connect after the server has started.

Again, this is only focused on the situation above where there is an entirely clean workspace and there needs to be an sbt session started before the BSP connection is made. I'll follow-up in #2049 with other stuff as I come across it with switching after the user already imported with Bloop, etc.

Also regarding opening a tab or window with sbt running etc, I consider that a client detail that will need to be worked out for each client.

[tgodzik]

@ckipp01 I think that is exactly the way to go! Great work figuring out 👏

[adpi2]

Sounds great!

You may find useful to use the sbt bspConfig task will just create the .bsp/sbt.json folder.

Also regarding opening a tab or window with sbt running etc, I consider that a client detail that will need to be worked out for each client.

I think this feature is not much useful anymore since one can use the sbtn command to open a shell that connects to the sbt server.

[ckipp01]

You may find useful to use the sbt bspConfig task will just create the .bsp/sbt.json folder.

Ah neat, I didn't know about this before. However, I'm not sure I'll actually use it. One of the issues I hit on was that after the creation of the .bsp/sbt.json, just grabbing the info and attempting to start the server + start a bsp connection almost failed every time due to multiple things. So the approach that I have now is that no matter what, I actually just start an sbt process, and then first initiate the bsp connection after it as two separate steps. I may need to re-work this a bit, but it seems to be working quite well.