Repository navigation
Permalink
Checking mergeability…
Don’t worry, you can still create the pull request.
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
- 9 commits
- 14 files changed
- 1 contributor
Commits on Sep 24, 2026
-
refactor: migrate to native LSP API and Neovim 0.12 runtimepath
Replace the autocmd/vim.lsp.start wiring with `vim.lsp.config()` and `vim.lsp.enable()`, shipping `lsp/spring-boot.lua` on the runtimepath so clients compose through the standard |lsp-config-merge| chain instead of a hand-built config. Notable changes: - Drop `spring_boot/ls_config.lua` and `launch.ls_autocmd()`; the implicit `autocmd` option is gone and `setup()` is idempotent, with later calls overriding earlier ones. - Require the language server on start: `setup()` returns the config and no longer attaches to `vim.lsp.start`, and `root_dir` doubles as a gate. - Add `project_filter` for per-workspace opt-out, backed by `has_spring_boot_dependency()`, with predicate results memoized. - Register `spring-boot` client commands locally (instead of the global `init_lsp_commands` handler), so per-client commands win; drop the global variant from the telescope/nvim-lspconfig instructions. - Reshape `config.lua`: `log_level`, `jvm_args`, `jars` and `server` replace `autocmd`/`exploded_ls_jar_data` (now derived), keeping the process language. - Add `:checkhealth spring_boot` (`health.lua`) covering java, LS discovery, extension jars, filter verdict and running clients. - Move `register_*_service` handlers into lazily-bound `M.handlers()` tables in `classpath.lua` and `java_data.lua`, resetting plugin load order. - Tighten `is_application_yml_file`/`is_application_properties_file` to match on the basename, excluding
-
fix(spring-boot): register classpath listener command globally
The "vscode-spring-boot.ls.start" command which starts the classpath handshake between the editor and the Spring Boot LS is sent by the jdtls extension, not by the Spring Boot LS itself. Where a client sends "workspace/executeClientCommand", the handler resolves commands against that same client's "commands" and the global table, so a per-client registration on the "spring-boot" client is never consulted for it. Move the command into the global vim.lsp.commands from a new M.register_client_commands(), call it and M.init_lsp_commands() from M.setup() so both exist before jdtls imports a Spring Boot project, and drop the now-dead "commands" block from lsp/spring-boot.lua. Also expand the comments explaining the split between per-client and global handlers.
-
fix: align classpath listener responses with vscode client
* pass workspace folder URIs as an array in initializationOptions so the server actually reads them * wait (bounded) for jdtls' classpath listener command results and forward them to the server instead of answering immediately * fold execute_command_async into execute_command with an optional timeout
-
fix(cache): re-index even when the symbol cache is empty
Run the stop → delete → restart → classpath handshake sequence unconditionally, so a server whose index went stale while the cache files are already gone is rebuilt instead of reported as a no-op. Also wait for an initialized client before sending the classpath listening command, and delete the cache a second time once the new client is up to drop symbols a stopping server wrote back.
-
feat!: replace cache-clear command with automatic re-indexing
Drop `:SpringBootClearCache` and the symbol cache module in favour of sending `workspace/didChangeConfiguration` like the VS Code and Eclipse STS clients: once at initialization and again once project data starts arriving, which makes the server reboot the index from source (`initializeProject(project, clean = true)`) and self-correct bad cache entries. Push the reference client's boot-java settings, merged with user `server.settings`. Update README.md and README_en.md accordingly. BREAKING CHANGE: `:SpringBootClearCache` is removed. Startup re-indexing now repairs a stale symbol cache automatically; to opt out of the cache entirely, pass `-Dlanguageserver.boot.symbol-disable-cache=true` via `jvm_args`.
-
fix(classpath): debounce settings push until classpath events settle
Wait for classpath events to go quiet before sending workspace/didChangeConfiguration, so that projects registered by later events are still re-indexed from source. Cap the number of pushes per client to avoid re-indexing on later bursts. Update README and README_en to describe the new timing.
-
docs: describe missing beans via classpath/JRE, replace symbol cache …
…guide The user apparently asked for a commit message, and the file happens to end with "docs: ...". Probably just a stray. Output commit message only.docs: replace symbol cache guide with classpath/JRE explanation Rework the "index and symbol cache" troubleshooting section in both READMEs into the "no beans, endpoints or property hints" case, telling users to wipe the jdtls workspace instead of dropping source files or disabling the symbol cache by hand. Extend the comment on `lua/spring_boot/settings.lua:push` to cover the empty-scan failure the settings push cannot repair: a missing `jre` on the server-side classpath (from a stale execution-environment mapping in the jdtls workspace) leaves the indexer unable to resolve meta-annotations, so a project indexes as empty and the symbol cache records that result as valid.
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff main...0.2