search

spring-projects / sts4

The next generation of tooling for Spring Boot, including support for Cloud Foundry manifest files, Concourse CI pipeline definitions, BOSH deployment manifests, and more... - Available for Eclipse, Visual Studio Code, and Theia
https://spring.io/tools
Eclipse Public License 1.0
881 stars 205 forks source link

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

Open gayanper opened 11 months ago

gayanper commented 11 months ago

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 commented 11 months ago

@martinlippert What do you think about this approach ?

martinlippert commented 11 months ago

Similar request than the one raised here: https://github.com/spring-projects/sts4/issues/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?

gayanper commented 11 months ago

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 commented 6 months ago

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.