Elvis/vscode extension#445
Conversation
ggleyzer
left a comment
ggleyzer
left a comment
There was a problem hiding this comment.
I'm really out of my depth here and would completely defer to Markus.
My only comment is: this PR seems to be an indicator that it wasn't the best idea to keep the plugin as a part of the xvm repo. May be we should start a new "plugin" repo using this PR?
There is nothing in the PR after updates that leaks out of lang, and as we have talked a lot about there is a migration plan to standalone implementation when I have finished the type adapter work, and there is a good reason that this lives under lang until that integration path is finished. I am still in deployment hell but I will try to review tonight or tomorrow. Now, however, it looks safe, in that it doesn't bleed out state into the rest of the code and lives self contained under lang just like the intellij plugin and the lsp server that both use. The only concern I have is about the node dependency potentially being resolved even if we are not creating a vscode-plugin build, and that, like the intellij toolkit, also is a very large download/install (although cached of course): |
- Implemented .gitignore to exclude unnecessary files - Created launch.json for debugging configurations - Added tasks.json for npm scripts to compile and watch - Updated README.md with project structure and local testing instructions - Enhanced build.gradle.kts to copy DAP server JAR and adjust packaging tasks - Modified package.json to include new commands and configuration options - Developed commands.ts to register commands for running modules and creating projects - Introduced debug-adapter.ts for DAP integration - Refactored extension.ts to manage activation and language client lifecycle - Implemented java.ts for Java discovery and JVM argument building - Created lsp-client.ts to manage the language client and its lifecycle - Added status-bar.ts for displaying server status in the VS Code status bar - Developed task-provider.ts for managing custom tasks related to XTC modules
…able detection - Introduced a new properties file for error messages with comprehensive error codes and descriptions. - Updated package.json to associate .x files with the xtc language and added workspaceContains activation event. - Refactored command registration to validate project names using a dedicated function. - Enhanced the extension to ensure .x files are correctly associated with the xtc language upon opening. - Improved Java executable detection by consolidating logic and handling errors more gracefully. - Updated LSP client to manage server state more effectively, including handling crashes and ensuring proper startup. - Added logging for server startup details and improved error handling for missing Java installations.
refactor: remove VS Code launch and task configurations chore: update build.gradle.kts to use node plugin for npm tasks feat: add jdk-utils dependency for Java discovery fix: enhance findJavaExecutable to support JRE download and caching feat: update debug adapter to use async Java executable discovery fix: improve language server startup status indication refactor: streamline Java discovery process and add download functionality fix: ensure proper handling of Java executable paths and permissions chore: update LSP client to handle async Java executable resolution Co-authored-by: Copilot <copilot@github.com>
lagergren
force-pushed
the
elvis/vscode-extension
branch
from
011d486 to
cffa239
Compare
|
There is an issue with the CI / build and test trying to resolve the libs.versions.toml gradle plugin but fails. Not sure why, but I think that it needs to live only under lang an only when the vscode plugin is being built. |
|
Where:
1 error |
….kts to copy LICENSE during build
3 participants
[WIP]This pull request introduces significant improvements to the VS Code extension for XTC, focusing on enhanced debugging support, improved task and command integration, and better developer experience through configuration and documentation updates. The main changes are the addition of a Debug Adapter Protocol (DAP) integration, new commands and tasks for running and managing XTC modules, and updates to build scripts and configuration files to support these features.
Debugging and Task Integration
XtcDebugAdapterDescriptorFactoryandXtcDebugConfigurationProviderindebug-adapter.ts, enabling users to debug XTC modules directly from VS Code. This includes logic to find the Java executable, launch the DAP server JAR, and provide debug configuration defaults.commands.ts, allowing users to run XTC modules, create new projects, and show language server output directly from the command palette.package.jsonto declare new commands (xtc.runModule,xtc.restartServer,xtc.showServerOutput), a custom XTC task type, and a new debugger type (xtc) with configuration snippets and attributes for module debugging. [1] [2] [3]Build and Launch Configuration
build.gradle.ktsbuild script to copy the DAP server JAR into the extension'sserverdirectory, and ensured that both the LSP and DAP servers are included in packaging and assembly tasks. The VS Code launch command now opens the test fixtures folder for easier testing. [1] [2] [3] [4].vscode/launch.json,.vscode/tasks.json) to support extension development, building, and debugging workflows for both the root and extension subfolders. [1] [2] [3] [4].gitignoreto exclude.vscode-test/from version control.Documentation and Developer Experience
README.mdwith clearer setup instructions, improved project structure documentation, and step-by-step guides for building, running, and testing the extension locally. [1] [2] [3] [4] [5] [6]These changes collectively make the XTC VS Code extension much more robust and user-friendly, especially for debugging and automation workflows.