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

Language Server Support #16

Open
chergert opened this issue Oct 14, 2022 · 4 comments
Open

Language Server Support #16

chergert opened this issue Oct 14, 2022 · 4 comments

Comments

@chergert
Copy link

This is a bit of a strawman issue, hoping to get some buy-in from openjdk SDK maintainers.

I wrote/maintain GNOME Builder and I'm trying to extend the reach of our out-of-the-box IDE support for more languages. Currently, we have support for jdtls, but it would be much more effective for applications that are to be shipped as flatpak's if the language server was bundled as part of the SDK (as we do for many other org.freedesktop.Sdk.Extension.* runtimes).

That would allow builder to run jdtls (or any other LSP if there is a better choice in the Java eco-system) within the build environment/container/toolbox/etc ensuring more correct completion results and what not.

Thoughts?

tsmock added a commit that referenced this issue Aug 16, 2024
@tsmock
Copy link
Collaborator

tsmock commented Aug 16, 2024

@chergert : let me know if what I've done in #74 will work for you.

@chergert
Copy link
Author

I think it makes sense from my PoV. We just would need to make sure that applications using it will have the sdk-extension set and an appropriate append-path, then we'll just pick it up in GNOME Builder. Though currently we expect it to be jdtls (but we can change that if necessary).

@tsmock
Copy link
Collaborator

tsmock commented Aug 19, 2024

What do you expect jdtls to be? As in, is it a shell script with "known-good" start variables, or do you have to add additional arguments when starting it?

@chergert
Copy link
Author

chergert commented Aug 19, 2024

Yeah it can be a shell script wrapper and that is fine. It just needs to do the LSP communication over stdin/stdout like most language servers. So be wary of any sort of printf/echo in any wrapper scripts.

We generally start the language server from the build directory (or maybe source directory, not sure) so it can pick up all the project build/configuration/etc.

Also, a symlink to the language server is fine too (assuming it is executable).

tsmock added a commit that referenced this issue Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants