-
Notifications
You must be signed in to change notification settings - Fork 522
Closed
eclipse-jdtls/eclipse.jdt.ls
#3735Description
Summary
After upgrading VS Code Java extension from 1.52.0 to 1.53.0, Gradle import gets stuck at 70% for a workspace that uses a custom Gradle settings plugin to include many subfolders as subprojects.
The issue disappears when:
"java.jdt.ls.groovySupport.enabled": false
The issue still occurs when only:
"java.jdt.ls.kotlinSupport.enabled": false
Regression window
- Works:
v1.52.0 - Fails:
v1.53.0
Likely related change in this window:
b1f4e81c4095d4698c7962cd5ef55ae002df36a0(Support Kotlin,Groovy in Gradle projects)
Environment
- VS Code:
1.110.1 - Extension:
redhat.java 1.53.0 - OS: Linux
- JDK: `java-21-openjdk.x86_64
`
- Gradle wrapper:
7+(project-specific) - Workspace: multi-project, configured via custom
settingsplugin
Project structure pattern (sanitized)
- Root project contains many service/platform folders.
- A custom
settingsplugin dynamically:- calls
settings.include(...)for many directories - rewrites selected subproject build files to
not-used.gradle(intentional for this setup)
- calls
- Some subprojects use Groovy-related build logic.
No proprietary code can be shared, but behavior is deterministic.
Repro steps (sanitized)
- Open a Gradle workspace using a custom
settingsplugin that dynamically includes many subfolders as subprojects. - Ensure VS Code Java extension is
1.53.0. - Keep default:
"java.jdt.ls.groovySupport.enabled": true
- Trigger Java/Gradle import (open workspace / reload window).
Actual behavior
Import stays around 70% indefinitely with repeated logs similar to:
[Trace] language/status: "70% Starting Java Language Server"
[Trace] $/progress: "Synchronizing Gradle build at <path> - 70%"
[Trace] language/status: "70% Starting Java Language Server - 1 operation remaining."
Reactions are currently unavailable
