I didn’t have any welcome guide. I have to lauch it throught the command palette “Welcome: Open Walkthrought”
Then in the document no button is workin.
If I go in the SonarQube menu :
neither the blue button "Add SonarQube Server Connection’ button, nor the contextual menu “…” > “Connect to SonarQube Server” is working
The latter is showing a notification on the bottom-right
I made the requested changes in the settings, but as nothing was showin in the Sonar Output I closed and restert VSCode.
Then I see an alert icon in the plugin menu
Seems there is a typo in the path for package.json, looking for “c:\Users\jmarandet.vscode\extensions...” while the correct path should be “c:\Users\jmarandet\.vscode\extensions...”
A backslash is missing before the .vscode folder name.
I tried to reproduce on a Windows 10 machine but the install and start of extension went through as expected; I’m waiting to get access to a Windows 11 machine to try to reproduce.
What is weird is that the path reported in the dev console seems correct (with the \ at the right place), but what is reported by the marketplace client is not. Unfortunately, the marketplace client is a built-in component of VSCode that we don’t control.
Out of curiosity, where/how is VSCode installed? In one of the screenshots, I see references to URIs starting with file:///C:/Non_Sauvegardé/..., but then the path to the extensions directory looks like the classic path in C:\Users\<yourprofile>\.vscode\extensions.
Could it be an issue with permissions to the requested folder? Are you maybe using security software that does not allow access to the extension directory?
Looking at the screenshot of the extension’s directory content, looks like a lot of files are missing there . If removing and reinstalling the extension with the built-in marketplace client fails, you can try the following:
Thanks a lot for this suggestion.
With the .VSIX version, the Developper Tools shows me more outputs and warned me that for some reason it was using a Java version in my $PATH that was outdated ( below 17 ).
So thanks to this message I could go foreward and update the settings of my $JDK_HOME and this time the plugin seems to work.
On the GitHub release page, we publish both platform-specific packages (the ones that have the OS and architecture in the name, e.g. win32-x64) and a universal one (the one without a suffix).
The universal VSIX will try to use a JRE provided by the environment (e.g. from the JAVA_HOME or JDK_HOME variables), whereas the platform-specific ones embed their own JDK. I suspect that in your initial message, the embedded JDK was blocked by an antivirus software (or some other “security” tool).
Oh yes, your guess is right I used the universal one.
And for sure, within my company the security policies may block any other JDK deployment.
When talking about packaging dependencies, may I suggest to use Dockerized tools ?
I used the docker sonar-scanner-cli for a try and it works pretty well.
It would lighten the footprint and allow to pack every necessary tools in the right version, without wondering if the local OS is correctly set up
One issue I see with relying on Docker is that it only pushes the dependency further - not everyone has a valid Docker runtime on their dev machine
For the particular case where the embedded JRE is present but cannot be used to start the language server, we can definitely try to provide more actionable feedback (e.g. with links to the documentation).
. If removing and reinstalling the extension with the built-in marketplace client fails, you can try the following:
thanks for sharing!