Feat/integrate lsp workspace project build with coc and native lsp #225
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
asmodeus812
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is integrating the original implementation of coc and native lsp to allow neotest-java to build workspace and projects based on the current context, this PR allows us to also resolve the correct runtime and java kit location, when running the build and tests as well. The runtime is first resolved from the project settings, or from the build file (gradle support still flaky).
The gist of this is to provide an abstract bridge between the lsp client and the underlying api - native nvim/coc. The build is either for the entire workspace, or per project, the current project is resolved based on the module base_dir
The configuration of the plugin is extended to allow users to provide manually their jdk version home location, in case they are not located on the path or in the usual locations. Those can be either provided as env variables or in the plugin config map.
Some minor fixes and formatting has been applied. @rcasia would be nice to get this finally in i have been working with my fork for more than a year and has been working just fine, however there are still issues unrelated to the build process, but related to the module resolve logic, having a multi-level nested multi module project is not working fine where the root actually contains multiple multi module projects like that: