Repository navigation
Bazel Support #27
Description
I think it would be possible to support bazel with jdtls, just as salesforce/bazel-vscode-java provides jars via contributes.javaExtensions to redhat-developer/vscode-java which get injected into the jdtls initializationOptions.bundles
The salesforce/bazel-vscode-java extension downloads p2-repository.zip which it then extracts, does some renaming and puts them under ~/.vscode/extensions/sfdc.bazel-vscode-java-1.4.0/server. And since salesforce/bazel-vscode-java exports a list of those jars via contributes.javaExtensions in it's package.json those settings are available to other extensions.
Source: salesforce/bazel-vscode-java:gulpfile.js and salesforce/bazel-vscode-java:package.json
When redhat-developer/vscode-java starts the language server it pulls from contributes.javaExtensions and provides those as a bundles array under the initializationOptions when starting jdtls:
Source: redhat-developer/vscode-java:src/extension.ts
I think the Zed Java Extension could potentially add support for Bazel with the following settings:
{
"lsp": {
"jdtls": {
"initialization_options": {
"bundles": [
"somepath/org.eclipse.equinox.event.jar",
"somepath/com.github.ben-manes.caffeine.jar",
"somepath/org.jsr-305.jar",
"somepath/org.fusesource.jansi.jar",
"somepath/com.google.protobuf.jar",
"somepath/com.salesforce.bazel.importedsource.jar",
"somepath/com.salesforce.bazel.sdk.jar",
"somepath/com.salesforce.bazel.eclipse.core.jar",
"somepath/com.salesforce.bazel.eclipse.jdtls.jar"
]
}
}
}
}Totally untested but I wanted to document my research somewhere.
Not sure whether the current Extension APIs are sufficient to support downloading arbitrary zip files, extracting a subset of them and then injecting the correct pathing for where those files are. But assuming this works, we could certainly provide instructions doing this manually.
I'm not a Java programmer.
I have no experience with Bazel.
Would love if someone can see if they can get this working.
See also:
Activity
valentinegb commentedon Dec 18, 2024
This would seem perfectly implementable to me, but unfortunately, as far as I'm aware1, there isn't a way to have an extension modify the initialization options before they're passed to the language server :(
Footnotes
emphasized because I don't know everything and I'd love to be proven wrong! ↩
notpeter commentedon Dec 18, 2024
We definitely fiddle that for the non-extension languages (json, yaml, etc) but I think you're right. :(
I think that's worth consider adding an API for.
maxdeviant commentedon Feb 8, 2025
Does
language_server_initialization_optionsnot do what you need?https://docs.rs/zed_extension_api/latest/zed_extension_api/trait.Extension.html#method.language_server_initialization_options
valentinegb commentedon Feb 8, 2025
language_server_initialization_optionsreturns an owned type and not a mutable reference, modifying it would not modify anything Zed owns, it would only modify this copy.valentinegb commentedon Apr 12, 2025
Either
zed_extension_api::Extension::language_server_initialization_optionschanged since I commented last or I was just being stupid because, yes, I think it could be used to modify the initialization options! I think it was probably the latter case, so, sorry @maxdeviant ^^'I think then the only problem right now is this would be difficult to implement because of the issue we're dealing with right now where initialization options don't seem to reach the language server at all, but hopefully this is something that can actually be worked on relatively soon.