[NEW PLUGIN] erroraway - Requesting inclusion in SonarQube Marketplace

SonarQube Server / Community Build Plugin Development
1

Hello,

The SonarQube Erroraway plugin uses errorprone and some of its plugins to detect potential bugs in java code.
I have a been using the plugin in production for 3 years and would like to ask for its inclusion in the marketplace.

Sample projects analyzed with the plugin as part of the integration tests: sonar-erroraway-plugin/sonar-erroraway-sonar-plugin/src/test/resources at master · erroraway/sonar-erroraway-plugin · GitHub

:warning: Under the hood errorprone uses a restricted javac API, the analyzer must therefore run with JVM options allowing access to the API as documented here.

:warning: auto-provisioning of a JRE must be disabled because the plugin needs to run with a JDK (so it can use javac): -Dsonar.plugins.downloadOnlyRequired=false

PR asking for inclusion of the plugin:

Thanks in advance!

2

Hi,

The bureaucratic requirements look fine, and server startup with the plugin on board looks good.

However, looking at the documentation, I’m concerned about this:

In SonarQube 10.5 the new feature to only download required plugins causes a NoClassDefFoundError. The workaround for this issue is to enable the sonar.plugins.downloadOnlyRequired option on the server AND on the analyzer: -Dsonar.plugins.downloadOnlyRequired=false

This is not acceptable. Before I test, I’ll need you to update the plugin to be fully compatible with downloadOnlyRequired.

Additionally, can you help me understand the need for this, please?

From SonarQybe 10.6 the scanner also auto provisions a JRE and runs the analysis off that JVM. Since the JRE does not include the required compiler module, this needs to be disabled with sonar.scanner.skipJreProvisioning=true .

And finally, once you’ve updated the plugin, please provide the command I should use to analyze your sample project.

 
Thx,
Ann

3

Hi Ann, thanks for looking into this,

The requirement for downloadOnlyRequired=false was outdated (fixed in Use ClassPathForMain to get the classpath by gtoison · Pull Request #46 · erroraway/sonar-erroraway-plugin · GitHub), I have removed this from the doc.
Thanks for pointing this out!

sonar.scanner.skipJreProvisioning=true is needed because errorprone uses javac internally (more precisely it uses the jdk.compiler module). This is not included in a JRE distribution, it needs a JDK.
IMO this is not a big problem for java projects because they’re most likely built with a JDK already.

The sample project used for the intergration tests is in: sonar-erroraway-plugin/sonar-erroraway-sonar-plugin/src/test/resources/projects/simple at master · erroraway/sonar-erroraway-plugin · GitHub
You can build and analyze it with either:
mvn clean package org.sonarsource.scanner.maven:sonar-maven-plugin:sonar (plus the usual sonar url/token parameters)
or:
gradlew clean build sonarqube (plus the usual sonar url/token parameters)

4

Hi,

Where am I supposed to do this part?

When running on JDK 16 or newer add the following options due to JEP 396:

--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED
--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED
--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED
--add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED

Because with this command:

mvn clean package sonar:sonar -Dsonar.host.url=http://localhost:9000 -Dsonar.token=sqa_xxx -Dsonar.skipJreProvisioning=true

I’m getting this:

[INFO] 11:27:03.074 Sensor Errorprone sensor [errorawaysonar]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  5.167 s
[INFO] Finished at: 2025-05-12T11:27:03-04:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:4.0.0.4121:sonar (default-cli) on project simple: The nullaway.annotated.packages option must be set when the NullAway rule is enabled -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

 
Thx,
Ann

5

For the sample project the add-exports options are already in .mvn/jvm.config so maven should pick them up automatically.

Sorry, I forgot about the Nullaway option, it should be -Dnullaway.annotated.packages=com.bugs,application

6

Hi,

Thanks for the hint.

I got this analyzed and am looking at the issues.

These are nice-to-haves:

  • I’m not wild about this “see” reference in the issue message:

    Selection_2406
    Selection_2406756×138 11.7 KB

    Since the URL exists as a link in the rule description, I think removing the URL from the issue message would do the user a big favor in terms of readability.

  • With 522 rules added by your plugin, I recognize that getting the actual rule descriptions into the plugin could be a lot of work, but it would be a huge benefit to the user.

  • And BTW, reading the actual rule description,

    Selection_2407
    Selection_2407665×301 20.6 KB

    it seems that the issue above is a FP? This is an import of java.util. The class isn’t being declared in java.util. I recognize that you probably didn’t write the rule implementation, but…at least turn this one off by default? Or… something?

Let me know if you plan to move on these things, and we’ll go from there.

 
Ann

7

The plugin converts the errorprone rules descriptions into sonarqube rules, it is merely converting them from markup to html. I think it is a bit beyond the scope of the project to edit these descriptions.

For this particular issue I agree that the description is a bit short. I think it expects a package declaration at the first line, where there currently is an import declaration.
So it should be:

package com.foo;

import java.util.*;
1 Like
8

Hi Ann,

I’ve just realized that there was a problem with the rules metadata generation: only the short description of the rules were picked up.
This should be fixed in the latest version of the plugin available here:
https://repo1.maven.org/maven2/io/github/erroraway/sonar-erroraway-sonar-plugin/2.2.2/sonar-erroraway-sonar-plugin-2.2.2.jar

For DefaultPackage the description is still short, but other rules have more elaborate explanations.

9

Hi,

This is better!

I would still love to see you take the URLs out of the issue messages, but we can go forward with this. I’ve commented on your PR

 
Ann

1 Like
10

Thanks for the quick turnaround!

1 Like
11

Hi,

I had merged this PR, but I’m going to have to roll it back. Here’s the error I get in the job:

Plugin sonar-erroraway-sonar-plugin-2.2.2.jar is declared with key 'errorawaysonar' in its MANIFEST, but with key 'erroraway' in the update center

 
Ann

12

Yes, I saw that, sorry about that
I’m releasing a fix, it should take a few minutes to pop up in maven central

13

Hello Ann, is it OK to change the proposed plugin key to errorawaysonar to match the current manifest?
This should facilitate things for users who have installed the plugin manually