Replacement for deprecated org.sonar.api.batch.ScannerSide

SonarQube Plugin Development
,
1

Hi,

I am the maintainer of the Checksyle plugin (GitHub - checkstyle/sonar-checkstyle: Support on Checkstyle in SonarQube. Officially transfered from https://github.com/SonarQubeCommunity/sonar-checkstyle) and I recently tried to migrate off all deprecated APIs when migrating from API v7 to API v9.

In the course of that, I have found org.sonar.api.batch.ScannerSide (ScannerSide (plugin-api 10.7.0.2191 API)) to be deprecated and replaced with org.sonar.api.scanner.ScannerSide (ScannerSide (plugin-api 10.7.0.2191 API)).

Shortly after, we received bug reports regarding multi-module projects and a massive slowdown of the analysis (see Slow checkstyle analyse on 10.14.2 · Issue #510 · checkstyle/sonar-checkstyle · GitHub).

Troubleshooting currently points to a change of the injected FileSystem (FileSystem (sonar-plugin-api 8.9)), in particular the workdir method now returning a different path.

With org.sonar.api.batch.ScannerSide, the workdir was the respective submodule directory of a multi-module project. With the change to the new annotation org.sonar.api.scanner.ScannerSide this is now the project directory (= root directory of the multi-module project).

This change of paths seems to result in scanning the entire codebase over and over multiple times = for each module the workdir is the root directory and the scan analyses all files/modules instead of only the module itself.
Hence, the analysis time dramatically slows down with the amount of submodules and number of files, and I believe this also leads to some duplicate issues found because of analysing the same files multiple times (unconfirmed: Duplicate Issues with Latest Version. · Issue #517 · checkstyle/sonar-checkstyle · GitHub).

My questions are:

  1. Is replacing the deprecated org.sonar.api.batch.ScannerSide with org.sonar.api.scanner.ScannerSide correct? If not, what is the expected replacement?
  2. How do we ensure the workdir is set/reported correctly from the injected FileSystem, or how do users need to change their SonarQube configuration to fix this issue?

Thank you! :slight_smile:
Best regards,
Daniel

2 Likes
4

Hi @muhlba91

We plan to drop the module concept in the scanner in the long term. This concept, inherited from Maven, is too Java-specific.

I am not sure everything in the API is ready for the move, but the idea would be to change all Sensors to ProjectSensor, which will run only once for a scan, independently of the number of Maven or Gradle modules.

Classes annotated with org.sonar.api.scanner.ScannerSide are loaded once per analysis (and can see the entire filesystem), while classes annotated with org.sonar.api.batch.ScannerSide are loaded once per module (and Sensor EP is part of that).

If you are adventurous, you can try migrating your Sensor to a ProjectSensor, or just revert to use org.sonar.api.batch.ScannerSide.

Sorry for this confusion.