POC for avoiding waiting on vscode-microprofile

[datho7561]

Work in progress.

Instead of directly depending on vscode-microprofile, send the user a notification with a button to install the extension. The user can reject the installation. If they reject the installation, they will be free to use:

• qute syntax highlight
• properties file syntax highlight
• project generator

However, no new language features (completion/validation) will appear, and they will be prompted to install vscode-microprofile when attempting to run commands that require it.

Since vscode-quarkus doesn't list itself as depending on vscode-microprofile anymore, it can start the project generator without starting vscode-microprofile or even vscode-java. This allows for it to work in rootless mode.

Closes #323

Signed-off-by: David Thompson davthomp@redhat.com

[datho7561]

If I also drop vscode-java and vscode-java-debug from the extensionDependencies, it takes even less time to reach the project generation from rootless mode.

This suggests to me that VS Code waits for the promise that activate() returns to resolve before starting extensions that depend on an extension. This is a reasonable behaviour, because we want to guarantee eg. that the language server is ready before we try to use it. Unfortunately, this means that we can't start these extensions in parallel. Maybe we could investigate exiting activate() as soon as possible in vscode-java, vscode-microprofile, etc. and export a separate API for detecting when the extension has completed its initialization. This method would allow us to start the language servers in parallel, while still being able to use the built-in extension dependency mechanism.

[datho7561]

@fbricon Do you think that removing vscode-microprofile as a extension dependency and instead providing a notification to install it in order to support this use case is a good idea?

[fbricon]

@fbricon Do you think that removing vscode-microprofile as a extension dependency and instead providing a notification to install it in order to support this use case is a good idea?

Maybe, maybe not. We need to test it thoroughly.

[datho7561]

I'm leaving this PR as a draft. I think that checking the extension requirements at startup instead of using the built-in VSCode extensionDependencies mechanism is the correct approach. In order to complete the PR, the dependency on redhat.vscode-java and vscjava.vscode-java-debug should also be removed from the package.json and checked during runtime before doing anything that requires JDT-LS. This should prevent JDT-LS from starting until its needed, saving a lot of time and system resources.