Hey, thanks for the additional info.
I am a bit surprised that the Maven command line you use for the SonarQube analysis manually specifies the
sonar.java.binaries property: in Maven, the scanner should feed it automatically with each module’s build output directory (as well as
sonar.java.libraries using each module’s dependencies).
I also notice in your editor screenshot that method
getJSONFromListeDocument is marked as implementing a declaration from an upper interface or abstract class (with the little white arrow in the margin).
IIRC, rule java:S1172 has an exception for such a case: it should not raise an issue for unused parameters on overrides and implementation methods.
So I believe that what is happening is that:
- In SonarLint, the Java analyzer correctly resolves the implemented interface/abstract class (using the class path configuration provided by Eclipse and/or M2E) and does not flag the “unused” parameters;
- In SonarQube, the Java analyzer gets confused (probably by the manually set
sonar.java.binaries property), does not resolve the implemented interface and thus wrongfully flags these parameters as unused.
In a perfect world, I would advise you to remove the manually set
sonar.java.binaries from your analysis command, unless you have a very good reason to keep it; but I am not quite sure what would be the impact on your project’s analysis history.
If this is not an option, I would advise that you mark this particular issue as a false positive on SonarQube.