Use case
I work in a polyglot Java environment where some projects are Spring Boot,
many are Jersey / plain libraries, and others are mixed-language repos
that happen to have a few .java and .yaml files. spring-boot.nvim's
current behaviour is to start the (fairly heavy) Spring Boot LSP for
every java and yaml buffer, regardless of whether the project
actually uses Spring Boot.
For Spring-only environments this is fine. For polyglot setups it's
expensive — booting a JVM-based language server you'll never use, plus
the LSP attaches to unrelated YAML buffers (docker-compose.yml,
.gitlab-ci.yml, helm values, etc.).
Current behaviour
The plugin registers an autocmd (group spring_boot_ls) that
unconditionally starts the Spring Boot LSP on BufRead / BufNewFile of
java and yaml filetypes.
Proposed behaviour (opt-in)
A setup({ ... }) option such as:
require('spring-boot.nvim').setup({
-- default false (current behaviour preserved)
require_spring_boot_project = true,
})
When true, before starting the LSP, walk up from the buffer's path
looking for pom.xml / build.gradle[.kts], then grep that file for
spring-boot. Only start the LSP if found.
The existing default stays unchanged, so this is non-breaking.
Prototype
I'm already using a local wrapper that does exactly this — it overrides
the spring_boot_ls autocmd group with a gated version. Sketch:
local function is_spring_project(bufnr)
local root = vim.fs.root(bufnr or 0, {
'pom.xml', 'build.gradle', 'build.gradle.kts',
'settings.gradle', 'settings.gradle.kts',
})
if not root then return false end
for _, fname in ipairs({ 'pom.xml', 'build.gradle', 'build.gradle.kts' }) do
local p = root .. '/' .. fname
if vim.fn.filereadable(p) == 1 then
for _, line in ipairs(vim.fn.readfile(p, '', 500)) do
if line:match('spring%-boot') then return true end
end
end
end
return false
end
-- Replace each existing 'spring_boot_ls' autocmd callback with one that
-- bails early when is_spring_project(bufnr) is false.
It works well for me but it's brittle — it depends on your group name
staying spring_boot_ls and the autocmd shape staying the same. A
proper opt-in inside the plugin would be more robust and benefit other
polyglot users.
Questions
- Would you be open to a PR adding this as an opt-in option?
- If yes, do you have a preferred name for the option?
require_spring_boot_project,
gate_on_project_detection, auto_detect, something else?
- Does the file scan (grep
pom.xml / build.gradle for spring-boot)
feel right, or would you prefer a stricter check (e.g. dependency
resolution via maven-resolver)?
Happy to send a PR once we agree on the shape.
🤖 Filed via Claude Code on behalf of @fobbyal
Use case
I work in a polyglot Java environment where some projects are Spring Boot,
many are Jersey / plain libraries, and others are mixed-language repos
that happen to have a few
.javaand.yamlfiles. spring-boot.nvim'scurrent behaviour is to start the (fairly heavy) Spring Boot LSP for
every
javaandyamlbuffer, regardless of whether the projectactually uses Spring Boot.
For Spring-only environments this is fine. For polyglot setups it's
expensive — booting a JVM-based language server you'll never use, plus
the LSP attaches to unrelated YAML buffers (
docker-compose.yml,.gitlab-ci.yml, helm values, etc.).Current behaviour
The plugin registers an autocmd (group
spring_boot_ls) thatunconditionally starts the Spring Boot LSP on
BufRead/BufNewFileofjavaandyamlfiletypes.Proposed behaviour (opt-in)
A
setup({ ... })option such as:When
true, before starting the LSP, walk up from the buffer's pathlooking for
pom.xml/build.gradle[.kts], then grep that file forspring-boot. Only start the LSP if found.The existing default stays unchanged, so this is non-breaking.
Prototype
I'm already using a local wrapper that does exactly this — it overrides
the
spring_boot_lsautocmd group with a gated version. Sketch:It works well for me but it's brittle — it depends on your group name
staying
spring_boot_lsand the autocmd shape staying the same. Aproper opt-in inside the plugin would be more robust and benefit other
polyglot users.
Questions
require_spring_boot_project,gate_on_project_detection,auto_detect, something else?pom.xml/build.gradleforspring-boot)feel right, or would you prefer a stricter check (e.g. dependency
resolution via maven-resolver)?
Happy to send a PR once we agree on the shape.
🤖 Filed via Claude Code on behalf of @fobbyal