Repository navigation
Troubleshooting
This section concerns the JDTLS Gradle Build Server importer adapter in microsoft/vscode-gradle, not the task service or the separate Gradle Build Server implementation. Evidence is pinned to merged/source-tip commit 608fdad0e7a22bbcd70c05edc396783ca97b6c9f, PR #1931. Source identity: microsoft/vscode-gradle#1931:608fdad0e7a22bbcd70c05edc396783ca97b6c9f.
At this revision, GradleBuildServerBuildSupport handles four invalid-data boundaries without dereferencing a missing value:
-
getProjectDependencyEntrieslogs the dependency URI and importing project, then skips a BSP project dependency when its URI does not resolve to an Eclipse workspace project. Diagnose the BSP-to-workspace mapping rather than treating the missing classpath entry as a task-service failure. -
getOutputFullPathlogs and returns no path when an output URI cannot be converted to a filesystem path, including non-file URIs. Its callers already treat a missing source output as an error and a missing resource output as nullable, so no output folder is created from an invalid path. -
getJvmTargetlogs the build-target identifier and skips a JVM target whose decodedJvmBuildTargetExmetadata is missing or invalid. Other valid JVM targets can still contribute Java home, Gradle version, and source/target compatibility; if none provide required values, the existing warning about empty Java home or Gradle version still applies. -
getDependencyJarslogs Maven coordinates and skips a Maven dependency whose decodedMavenDependencyModulemetadata is missing or invalid. This prevents that malformed entry from contributing a classpath library while allowing remaining dependency modules to be processed.
Use the emitted identifiers to distinguish malformed BSP metadata, a non-file output URI, or an unmapped workspace project from unrelated Gradle task discovery and transport failures. These guards preserve processing where possible; they do not repair the originating model data or guarantee that an import with missing required inputs is complete.
The complete PR changed only the linked implementation file (23 additions, 2 deletions). Its one-file patch and final file were inspected, PR metadata was rechecked after paging, and the final source was verified at the full commit SHA above. No tests changed in the PR, and this maintenance review did not execute tests, reproduce failures, or establish release/deployment.