-
Notifications
You must be signed in to change notification settings - Fork 401
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
Add experimental support for Bazel (eclipse#543) #1404
Conversation
Signed-off-by: Pavel Mitrafanau <pavel_mitrafanau@epam.com>
Can one of the admins verify this patch? |
add to whitelist |
@fbricon Hello. I'm wondering if you have any ideas about failed test. Checked it locally, everything is ok. |
test this please |
flaky test, ignore it. So, I've tested this PR with vscode-java, setting It failed with:
Now, more generally on Bazel support in jdt.ls, as I said before, I think this should be done as a jdt.ls extension. There's nothing in this PR that can't prevent a bazel jdt.ls extension to run, loaded by jdt.ls on startup. The importer is provided via an extension point, the preferences can be accessed through: Map<> configuration = JavaLanguageServerPlugin.getInstance().getPreferencesManager().getPreferences().asMap();
boolean enabled = MapFlattener.getBoolean(configuration, IMPORT_BAZEL_ENABLED, false); All you need to do is get that jdt.ls extension and its dependencies to be loaded by the client. In the case of vscode-java, you can list all your jars in package.json, like https://github.com/redhat-developer/vscode-java/wiki/Contribute-a-Java-Extension#modify-packagejson and that's it. Having said that, I believe more changes will be needed to be made in jdt.ls core to make bazel support work properly, those I'm more inclined to get in:
We also need to be able to dynamically register listeners for specific build files (BUILD/WORKSPACE), so their modifications can be sent to jdt.ls |
After disabling the bazel, importer, reopening the workspace threw some other error:
|
Hi @fbricon, Bazel java-tutorial project import fails as its build definition is in broken state. Moreover this was done intentionally. Currently our plugin doesn’t support “non-buildable” project import. We updated README to reflect this fact. We fixed the exception after disabling the importer and reopening the project. Currently we work on moving our changes from eclipse.jdt.ls into our plugin itself and package it as jdt.ls extension. Thank you for the valuable advice! At a glance it’s not clear what is the purpose of IBuildSupport abstraction and how it is used inside jdt.ls core. Also I would appreciate it if you can provide more details regarding changes in jdt.ls core (decoupling from build systems and new extension point). Do you have dedicated issues to track the process? |
Basically IBuildSupport was introduced to be able to take care of project synchronization when a build file has changed, and you need to make some eclipse config changes accordingly (eg. need to compile to a different Java version, update classpath...). |
Thanks for the update. I'm closing the PR. May I ask you to mention the issue in this thread after you create it? |
Experimental support for Bazel (#543)
Introduces integration with the following plugin. Since it's in active development, the importer is disabled by default and has the lowest priority.
Currently the plugin does the following to provide rich development experience:
Signed-off-by: Pavel Mitrafanau pavel_mitrafanau@epam.com