6

I have recently updated SonarQube to version 4.5.4 and the Java plugin to version 3.5.

We have classes annotated with @Data, but it seems that the rule squid:S1068 doesn't handle this "special" annotations. Altough they should be ignored since version 3.4 according to https://github.com/SonarSource/sonar-java/pull/257 and https://jira.sonarsource.com/browse/SONARJAVA-990.

Please see attached screenshot. Did I forget to configure something?

enter image description here

UPDATE:

I wanted to ensure that our used Java plugin 3.5 has included the changes of commit https://github.com/benzonico/sonar-java/commit/5e7de16f59450061227d4103f64e351d1f93d9e9 so I reverse engineered the .jar file to see the source of rule squid:S1068 UnusedPrivateFieldCheck.java. Extended Lombok releated changes are there and apparently working!

agassner
  • 689
  • 8
  • 25
  • 2
    How are you doing your analysis (maven or sonar-runner) ? how do you provide bytecode (and especially the bytecode of the @Data annotation) to the analyzer ? if bytecode is not provided type won't be resolved and issue will be raised. – benzonico Sep 08 '15 at 09:02
  • We use Sonar Maven plugin for the analysis: `mvn sonar:sonar -Dsonar.branch=some_branch_name`. I think we do not provide the bytecode currently. @benzonico Thats a very useful statement, I'm going to try your suggestion now – agassner Sep 08 '15 at 09:18
  • With maven it is normally done automatically by the maven plugin. – benzonico Sep 08 '15 at 13:53
  • Worked for me. https://stackoverflow.com/questions/46362965/sonarqube-lombok-false-positives – Barış Özdemir May 29 '18 at 11:02

3 Answers3

10

Finally I'm able to answer my own question with help of @benzonico's comment.

In our CI system's Sonar build log I found many warning messages: [WARN] [16:51:48.435] Class 'com/bla/bla/Application' is not accessible through the ClassLoader.

The bytecode analysis needs to get fixed for all classes and its dependencies in order to get a correct result. I had to set following Sonar properties:

sonar.java.binaries=target/classes
sonar.java.libraries=target/dependency/*.jar

Note that without sonar.java.binaries=target/classes it's not working, at least on our CI system (TeamCity).

Before running mvn sonar:sonar all Maven dependencies (transient ones too) are moved to the folder target/dependency by running mvn dependency:copy-dependencies before the analysis now.

Now the CI build log is cleaner, Lombok annotations get recognized.

agassner
  • 689
  • 8
  • 25
  • 2
    please note that those keys (sonar.java.binaries etc) change with different versions of the java plugin, see http://docs.sonarqube.org/display/PLUG/Java+Plugin+and+Bytecode – evandor Nov 06 '15 at 10:19
  • `mvn dependency:copy-dependencies` did the trick for me, thank you! – Clans Apr 12 '21 at 10:09
4

similarly you can add to command line directly:

Steps:

CD to the path which you want to run it on, and when you run sonar-runner add the following parameters:

-Dsonar.java.binaries=target/classes -Dsonar.java.libraries=target/lib/*.jar

Note: For me it was target/lib for the jars, not target/dependency.

Bojan Petkovic
  • 2,406
  • 15
  • 26
0

add these properties:

-Dsonar.language=java
-Dsonar.java.binaries=target/classes
-Dsonar.java.libraries=target/lib/*.jar
Ravi Vyas
  • 410
  • 6
  • 12