Start language server via nextflow lsp

[bentsherman]

Depends on nextflow-io/nextflow#5466

Launch the language server via nextflow lsp instead of launching the JAR directly. This way, the extension will use whatever language server corresponds to the active nextflow version.

We will likely need to keep the old java launcher as a fallback, since Nextflow versions <=24.10 do not have an lsp command. However, we could improve this code by downloading the language server JAR from GitHub instead of bundling it with the extension. That way, I don't even need to publish the VS Code extension to push updates, I can just publish the language server and ask users to restart.

[pditommaso]

Not fully sold to this approach. This will make VScode plugin to depends on nextflow, that in turns depends on Java.

Considering we may want to run this in different context ie. Studio, or AI validation it could make sense to lang parser as lean as possible, ideally both as a library (to embedded in nextflow) and a self-contained executable

[bentsherman]

what do you think about my other idea, having the vscode extension automatically download the language server on startup rather than bundling the language server with every extension release?

[pditommaso]

So that the same VScode extension can handle multiple versions of nextflow lang spec?

[bentsherman]

Yes. Similar to what we do for Fusion. I could update the language server, then the user only needs to restart the extension rather than install a new version to get the updates.

Also, they could control the target version with an extension setting, and we could have a language server version for each nextflow stable release (24.10, 25.04, etc)

[pditommaso]

Make a lot of sense. one reason more I'd keep independent from nextflow distribution

[bentsherman]

Closing in favor of #68