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

Use VSCode Spring Boot Tools from mason-registry #15

Closed
indika-dev opened this issue Jan 10, 2025 · 10 comments
Closed

Use VSCode Spring Boot Tools from mason-registry #15

indika-dev opened this issue Jan 10, 2025 · 10 comments

Comments

@indika-dev
Copy link
Contributor

Hi @JavaHello ,

I'm the author of the PR #8077, which adds VSCode Spring Boot Tools from the OpenVSX-Registry to the mason core registry. After taking a closer look on the capabilities of mason, I realized, that I can load and parse the so called mason receipt. This opens the possibility of being completly independent from local installations paths and internal changes inside a VSCode plugin, so that the code to integrate a plugin in Neovim should be more stable over time or at least with minimal changes. That worked very well with java-debug-adapter and java-test and then I decided to integrate your plugin in the same way. In the end, I forked your repo and added the integration for spring_boot.java_extensions() in such a way, that the VSCode Spring Boot Tools can be loaded either from VSCode install path, path given in config or mason-registry. Unfortunately, your code was quite hard to understand for myseld and I started to refactor it, so that I can be sure, I understand that my additions work well with your plugin. The final result of my refactoring has a quite heavy impact on your code (at least in my opinion) and you can see it in PR #14 . I totally understand it, if you say, that this is too much and therefore you deny this PR. But it would be great, if the integration part with mason-registry in this PR could be added to your plugin. You can find this part in spring_boot.[get_ls_from_mason, get_from_mason_registry, setup, java_extensions].


After some time I found out, that @s1n7ax integrates your plugin in his nvim-java plugin and he has a mason-registry on its own and therefore I think, it would be beneficial for his plugin, too, if the mason-registry is integrated in your spring-boot plugin.


To have an idea, what it means, if you use mason receipts to integrate packages provided by mason, you can take a look at my Neovim config for jdtls and your spring-boot plugin:

  • jdtls.lua for loading all relevant integration parts in lines 8-34 and 60-70
  • springBoot.lua for configuring spring-boot.nvim


    @s1n7ax If @JavaHello decides to add my changes to his code, the spring-boot package in your mason registry will be incompatible to the one of the PR #8077. Therefore, I also opened a PR in your mason registry to have the packages compatibel. In this PR is also included a compatibility patch for jdtls, so that anyone can switch seamlessly between the different mason registries without changing the integration code in Neovim. Since you are already using spring_boot.java_extensions() in your plugin, the changes in your code for the new package name should be minimal.


    So, this is a rather complex PR sequence and their consequences, which spans three different mason registries(I patched already my mason registry to be compatibel between nvim-java mason-registry and mason core registry; depending on how this issue will be solved, a PR in mason core registry for adding linux-arm64 target for jdtls has to be opened) , two different git repositories and involves three people. Therefore, I was looking for a single place to discuss this in one place and this place should be this issue. I hope you're all fine with this and I'm eagerly waiting for your feedback. :)

@JavaHello
Copy link
Owner

Thank you, I fixed some errors in the default configuration and the way of using ftplugin.

@indika-dev
Copy link
Contributor Author

That are great news and thank you! I added another PR #17 , because there was an error redefining opts.ls_path if spring boot ls is loaded from mason registry.

@indika-dev
Copy link
Contributor Author

Works perfectly now. Still waiting for feedback from @s1n7ax .

@s1n7ax
Copy link

s1n7ax commented Jan 14, 2025

@indika-dev Once main reg pr is merged I'll start using it so it's not necessary to make any changes to my registry other than removing the existing spring boot pkg. You can go ahead with these changes since I have pinned spring-boot to a commit, this shouldn't break anything.

@indika-dev
Copy link
Contributor Author

@s1n7ax Thank you for your feedback. Perfect, got all needed feedback and I'll close this issue.

@s1n7ax
Copy link

s1n7ax commented Jan 29, 2025

@indika-dev Just wondering what is the mason receipt thing was about. Right now a quite a lot of people is having trouble installing stuff from my mason registry due to the way they have configured mason. Is there a way to add custom packages without adding a new registry? My main requirement would be to replace jdtls package from the main registry to my registry package.

@s1n7ax
Copy link

s1n7ax commented Jan 29, 2025

@indika-dev
Copy link
Contributor Author

@s1n7ax What are the problems, they are reporting? I don't fully understand, what the problem exactly is.

Looks like you are just reading the path
I'm not only reading the path here, the expanded shared links are read from the receipt and then concatenated to the install path of the package. In such a way, you get the full local installation path of e.g. jars or directories inside a package without knowing where it is installed locally.
Mason generates a mason-receipt.json file when a package is installed/updated locally. On MacOS/Linux for jdtls, you can find the file at the following path in a standard installation: ~/.local/share/nvim/mason/packages/jdtls/mason-receipt.json Each entry in links.shared is prefixed with a key from the share section in https://github.com/mason-org/mason-registry/blob/main/packages/jdtls/package.yaml Therefore, to have multiple working mason registries, compliant to each other, the share sections of the package.yaml files must have the same keys as provided in the mason core registry.
If I compare your https://github.com/nvim-java/mason-registry/blob/main/packages/jdtls/package.yaml with the one from the core registry https://github.com/mason-org/mason-registry/blob/main/packages/jdtls/package.yaml then there's a difference in the share keys in both files.
For reference, this is what the package.yaml looks like in my personal mason registry: https://github.com/indika-dev/personal-mason-registry/blob/main/packages/jdtls/package.yaml and depends on the package provided by your repo https://github.com/nvim-java/release-jdtls.

Is there a way to add custom packages without adding a new registry?
No, at least no way I'm knowing of.

Keep in mind, that you have the correct order for your different mason registries, so that they are overwriting in the correct order.

@s1n7ax
Copy link

s1n7ax commented Jan 30, 2025

This is the issue.
nvim-java/nvim-java#304

Even if I'm passing nvim-java reg it might not be passed to setup if user use config prop and not merge the config with the inherited before calling setup. I'm looking for solution like below

williamboman/mason.nvim#1749

I guess receipt is not it.

@indika-dev
Copy link
Contributor Author

No, receipt comes into play, when installed packages are requested. Concerning your problem, perhabs you might be able to reinitialize mason with your added registry or you might be able to add your registry to the mason internal list of used registries.

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

3 participants