scalameta / nvim-metals

A Metals plugin for Neovim
https://scalameta.org/metals/
Apache License 2.0
455 stars 74 forks source link

switching build server to sbt prompts for restarting it #635

Closed ghostbuster91 closed 7 months ago

ghostbuster91 commented 7 months ago

Describe the bug

When I switch to use sbt as a build server I am prompted with an information that java home has been changed and if I want to restart the build server. Choosing whichever options seems to end with a working project so it is not a big deal.

Kooha-2023-12-17-15-03-04.webm

Expected behavior

I think that switching build server should not trigger prompt about restarting it.

Operating system

Linux

Version of Metals

v0.11.1

Commit of nvim-metals

1e269f1

ckipp01 commented 7 months ago

Choosing whichever options seems to end with a working project so it is not a big deal.

I think this is sort of by chance though and it does have the possibility to not work. From my understanding what's happening here is that sbt server was started with another Java version, maybe a couple days ago. Then when you are switching to use sbt as your build server and it attempts to connect to it, it doesn't match the Java version Metals knows about and wants to use, thus restarting it. So there is a mismatch here that is probably correct to prompt this.

ghostbuster91 commented 7 months ago

Interesting theory but it seems that was not the case in here. After cleaning the all directories as .bloop, .bsp etc and reimporting the project with a clean state the "java home" prompt went away.

Since I can no longer reproduce it, either it is not clear whether that was an issue at all I am going to close this issue for now.

ckipp01 commented 7 months ago

Interesting theory but it seems that was not the case in here. After cleaning the all directories as .bloop, .bsp etc and reimporting the project with a clean state the "java home" prompt went away.

Keep in mind that deleting all of those have nothing to do with what you were explaining. If sbt server was running beforehand, it's not affected by those. Same thing with bloop actually since that javaHome entry ends up being stored in the global .bloop/ not your local one.

ghostbuster91 commented 7 months ago

Yes, I understand that. First, I checked if there were any other old sbt server runnings - they weren't. Then I followed sequence to reproduce the issue - the issue occured once again. Only, then I cleaned these directories and finally the issue disappeared.

I am not pursuing this any further because in the meantime I accidentally updated to a snapshot version of metals, that might have broken some state. I then reverted the update and was still able to reproduce the issue but as I said, maybe something got written somewhere.

Anyway, thanks for the explanation how this all works under the hood, I will keep that in mind next time I run into something like that.