Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for running with both Redhat and Netbeans language servers #1151

Open
gayanper opened this issue Nov 25, 2023 · 4 comments
Open

Support for running with both Redhat and Netbeans language servers #1151

gayanper opened this issue Nov 25, 2023 · 4 comments
Labels
for: vscode something that is specific for VSCode type: enhancement

Comments

@gayanper
Copy link
Contributor

Expected Behavior
Make this extension/LS possible to run with both Redhat Java LS and Apache Netbeans LS. Since both of the java LS are becoming popular and support different frameworks at the moment, It would be really nice if STS project can support either of these LS for Java parts.

Current Behavior
Current installation actually installed Redhat Java extension as part of dependencies which conflicts with Netbeans Language server.

@gayanper
Copy link
Contributor Author

@martinlippert What do you think about this approach ?

@martinlippert
Copy link
Member

Similar request than the one raised here: #1132

I like the idea of allowing the Spring Tools extension to work with all of those Java tooling LS and extensions, so that our users have the freedom of choice which Java tooling they prefer.

The main challenge here will be to implement the communication (or exchange of information) that we have been using for a while now (between the RedHat Java tooling and the Spring Tools) for the other Java tooling extensions, which is mostly about project and resolved classpath information as well as some details about types.

@BoykoAlex can provide a lot more details here, but at the moment we do this via custom commands for which we implement and contribute the necessary handler within the Java tooling as an extension (OSGi) bundle. The extension API of the Eclipse-based java tooling allows us to do this pretty easily.

Given the fact that this is the third Java tooling extension now that we might want to support, the question comes up whether we can come up with and agree on a common mechanism for this, so that we don't have to implement this in three different ways for each java tooling extension (+ the Eclipse desktop IDE, of course).

Sounds like a broader collaboration effort here to establish this common API, but definitely possible. Interested in collaborating here?

@martinlippert martinlippert added for: vscode something that is specific for VSCode and removed status: waiting-for-triage labels Nov 27, 2023
@gayanper
Copy link
Contributor Author

Yes @martinlippert for sure. I remember I implemented the custom extension protocol parts for intellij while back to get the sts4 on intelij community version. I think we could so the same for other LSP setups as well right ? Its just matter of those LSP provides implementations for theae custom LSP commands. May be if we can remove the hard dependency on extension for redhat lsp and try to discover the extension parts which i'm not sure how at the moment, the sts4 could work with any Java LS which provide implementations for those custom commands right ?

In case fail to find one, we could warn or suggest to implement knows supported Java LS extension.

@martinlippert
Copy link
Member

This is not a priority for us at the moment, but we would still be happy to collaborate on this and provide feedback / discuss + accept PRs, etc. Maybe @ThomasVitale is interested here, too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: vscode something that is specific for VSCode type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants