Rely on SonarLint for Visual Studio Code for artifacts rather than the seperate JARs

thahnen commented 6 months ago

Hello,

this is Tobias from the SonarLint team at SonarSource. I noticed that you're downloading the Jar archives manually from either Maven Central or our hosted JFrog Artifactory. First things first: The JFrog Artifactory links will soon stop working and therefore the follow-up idea for you (as I have no idea of Emacs Lisp and how to implement it myself) is to rely on the SonarLint for Visual Studio Code released artifacts, as they're in fact just ZIP archives (VSIX is just a fancy name I guess) always uploaded to GitHub after every release.

The language server is present in extension/server/sonarlint-ls.jar and the language analyzers can be found in extension/analyzers. This way you can make use of every analyzer there is (C# should come in handy for #18) as you don't support all of them yet (Infrastructure as Code and C# via OmniSharp). The sonarcfamily.jar is the frontend for the C/C++ analyzer but indeed, for the analysis to work you have to be in connected mode.

This way you also only have to rely on one single source of truth - the GitHub download page. You may not like it, but the arch-enemy Vim is already relying on it via the Mason Registry.

Best regards and Happy Holidays, Tobias

thahnen commented 6 months ago

Supported languages on the SonarLint Language Server side (and therefore SonarLint for Visual Studio Code) can always be found at org.sonarsource.sonarlint.ls.EnginesFactory.java#STANDALONE_LANGUAGES.

Sasanidas commented 6 months ago

I see, I don't use sonarlint that much and this will require some development. But I'm sure that he @emacs-lsp team can help with that :+1:

Horrih commented 1 month ago

The language server is present in extension/server/sonarlint-ls.jar and the language analyzers can be found in extension/analyzers. This way you can make use of every analyzer there is (C# should come in handy for #18) as you don't support all of them yet (Infrastructure as Code and C# via OmniSharp). The sonarcfamily.jar is the frontend for the C/C++ analyzer but indeed, for the analysis to work you have to be in connected mode.

Thank you @thahnen and Sonar for showing support for a community plugin ! I use c++ sonar at work, and I would like to implement cfamily support in emacs as well. I unzipped the vsix as mentioned and found a complete JRE + the analyzers, including cfamily.

If I understand correctly, cfamily only works in connected mode ? Do you know where I could find documentation on how to achieve this, or the corresponding source code in sonarlint's VSCode extension ?

Thanks !

Horrih commented 1 month ago

The language server is present in extension/server/sonarlint-ls.jar and the language analyzers can be found in extension/analyzers. This way you can make use of every analyzer there is (C# should come in handy for #18) as you don't support all of them yet (Infrastructure as Code and C# via OmniSharp). The sonarcfamily.jar is the frontend for the C/C++ analyzer but indeed, for the analysis to work you have to be in connected mode.

Thank you @thahnen and Sonar for showing support for a community plugin ! I use c++ sonar at work, and I would like to implement cfamily support in emacs as well. I unzipped the vsix as mentioned and found a complete JRE + the analyzers, including cfamily.

If I understand correctly, cfamily only works in connected mode ? Do you know where I could find documentation on how to achieve this, or the corresponding source code in sonarlint's VSCode extension ?

Thanks !

After some testing on my side, I have found the following :

Unzipping the vsix works, and would simplify the logic around downloading separate jars
Sonarlint uses many LSP extensions, which are not yet implemented here, namely "sonarlint/shouldAnalyseFile", "sonarlint/listFilesInFolder", "sonarlint/filterOutExcludedFiles", "sonarlint/needCompilationDatabase"

As for CFamily support :

works even without the "connected" mode
seems to only require the provision of compile_commands.json to function

So, migrating to the "unzip the vsix" method has great potential to simplify the .jar management, and support for c/c++ would be easy. However beware of the numerous sonarlint extensions, some work will be needed here, at least on recent versions of sonarlint.

If I get enough time, I might be able to submit a PR in the upcoming weeks.

thahnen commented 1 month ago

Hey @Horrih,

The documentation from SQ about CFamily can be found HERE. Yes, it is implemented for VSCode, but I cannot directly pinpoint it. Please take a look yourself.

For the rest of your assumptions. They're mostly right!

Once you do a PR, feel free to assign it to me for the SonarLint-specific logic; for Emacs, I honestly don't have a clue.

Horrih commented 3 weeks ago

Thank you @thahnen , I have implemented PR #22 to add support for VSCode extension unzipping + cfamily support.

I also noticed that PR #20 seems to implement this as well. Let's hope it gets merged one way or the other.

I'll be testing out connected mode soon, it does not seem that hard to implement in its basic form.

Sasanidas commented 1 week ago

This sould have been fixed with https://github.com/emacs-lsp/lsp-sonarlint/pull/22

emacs-lsp / lsp-sonarlint

Rely on SonarLint for Visual Studio Code for artifacts rather than the seperate JARs #21