feat: progressive project tree view during import#982
Merged
Conversation
Show Java project names in the tree view progressively as they are imported, instead of waiting for the entire import to complete. Key changes: - Use serverRunning() API (v0.14) instead of serverReady() so the tree view can start rendering before import finishes - Add addProgressiveProjects() to create ProjectNode items directly from ProjectsImported notification URIs without querying the server - Guard getChildren() from entering getRootNodes() during progressive loading to avoid blocking on server queries - Keep TreeView progress spinner visible until first items arrive - After import completes, trigger full refresh to replace placeholder items with complete data from the server This reduces perceived loading time for large projects (e.g., 436 Gradle subprojects) from ~7 minutes to ~1 minute.
Contributor
There was a problem hiding this comment.
Pull request overview
Adds progressive population of the JAVA PROJECTS tree during JDTLS import by consuming ProjectsImported notifications, so users see project names earlier instead of waiting for full import completion.
Changes:
- Introduces progressive root project nodes in
DependencyDataProviderand avoids root server queries while import is ongoing. - Updates
LanguageServerApiManager.ready()to useserverRunning()(when available) and wires import/classpath events to progressively add projects, followed by a full refresh afterserverReady(). - Adds an internal command for progressively adding projects to the tree view.
Reviewed changes
Copilot reviewed 3 out of 4 changed files in this pull request and generated 7 comments.
| File | Description |
|---|---|
| src/views/dependencyDataProvider.ts | Adds progressive root node population and spinner/await logic during import. |
| src/languageServerApi/languageServerApiManager.ts | Switches readiness behavior to serverRunning() and routes JDTLS events to progressive updates + final refresh. |
| src/commands.ts | Adds internal command ID for progressive project insertion. |
| package-lock.json | Bumps package version metadata to 0.27.1. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Extract startServerReadyWait() and call it unconditionally in initializeJavaLanguageServerApis() so isServerReady is set correctly even if onDidProjectsImport fires before ready() (fixes #6) - Restore ready() to not start serverReady() wait inline, keeping its semantics consistent for other callers like syncHandler, upgradeManager, BuildArtifactTaskProvider (fixes #4) - Add .catch() on serverReady().then() to avoid unhandled promise rejections if the server fails to start (fixes #5) - Restore debounce=true on onDidClasspathUpdate when server is ready to avoid burst refreshes (fixes #7) - Add 30s timeout on _progressiveItemsReady await to prevent getChildren() from hanging indefinitely (fixes #2) - Resolve _progressiveItemsReady in doRefresh() to prevent stale getChildren() calls from hanging
wenytang-ms
reviewed
Mar 30, 2026
After the 30s timeout, if no progressive notifications were received (e.g., eclipse.jdt.ls progressive notifications not yet available), fall through to the normal getRootNodes() path instead of returning an empty array. This ensures the worst case matches today's behavior. Addresses review comment from wenytang-ms.
wenytang-ms
previously approved these changes
Mar 30, 2026
wenytang-ms
approved these changes
Mar 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Show Java project names in the JAVA PROJECTS tree view progressively as they are imported, instead of waiting for the entire import to complete. This reduces perceived loading time for large projects (e.g., 436 Gradle subprojects) from ~7 minutes to ~1 minute.
Problem
For large Gradle projects, the JDTLS import takes 6-7 minutes. During this time, the JAVA PROJECTS tree view is completely empty because:
serverReady()doesn't resolve until import completesserverRunning(), the server is blocked by Eclipse workspace locks and can't respond to queries likejava.project.listSolution
Instead of querying the server for project data, create tree nodes directly from
ProjectsImportednotification URIs sent progressively by JDTLS during import.Key Changes
languageServerApiManager.tsserverRunning()(API >= 0.14) instead ofserverReady()so the tree view can start rendering before import finishesonDidProjectsImportevents toaddProgressiveProjects()instead of refresh (which would query the blocked server)onDidClasspathUpdateduring import toaddProgressiveProjects()(non-destructive)serverReady()), trigger full refresh to replace placeholders with real dataisFullyReady()methoddependencyDataProvider.tsaddProgressiveProjects()— createsProjectNodeitems from URIs without server queriesgetChildren()from enteringgetRootNodes()during progressive loading (prevents blocking on server queries that hang for the entire import)commands.tsVIEW_PACKAGE_INTERNAL_ADD_PROJECTScommand constantContext
This is part of a 3-repo change for progressive project loading:
serverRunning()API (v0.14)Testing
Tested with spring-boot project (436 Gradle subprojects):