SonarQube findings for projects that use Lombok and maven

Hello,

We are using:

  • SonarQube Enterprise Edition Version 8.2.
  • SonarQube Scanner 4.1.0
  • SonarJava 6.1 (build 20866)

We are using in our project the Lombok library and we are building our projects using maven.

SonarQube displays an issue on every private field that is annotated with Lombok annotations. The issue comes from the rule “Unused “private” fields should be removed”.

We would like to get rid of this issues but still keep the rule for the private fields that are not annotated with Lombok.

Do you know how we can do this?

Hello @Maria_Patrunjel

In the end, are the fields reported really unused? Or are they used one way or another thanks to Lombok?

We already have a mechanism to not report unused private fields when the class is annotated with a given list of Lombok annotations (AllArgsConstructor, RequiredArgsConstructor, …), did we miss a use-case?
Could you provide us a code sample raising the issue that you consider as false positive?

Hello,the fields is marked as unused - see picture:


above the class you can see the annotations of Lambok.
Thanks!
I answer instead of @Maria_Patrunjel, because she is prevented

Hello @itWorks,

I’m surprised, these annotations should be supported for quite some time, and I did not manage to reproduce the issue with this code sample.

Which version of SonarQube/Java analyzer are you using? In addition, you are using scanner for maven, right?

Can you see something strange in the logs of the analysis? Can you share them here?

We are using:

  • SonarQube Enterprise Edition Version 8.2.
  • SonarQube Scanner 4.1.0
  • SonarJava 6.1 (build 20866)

The projects are based on maven - we call the Sonarqube step from our Jenkins pipeline
You will need the logs from the SonarQube Scanner?
I i have attached the steps from Jenkins. jenkins_sonarqube_step.zip (3.2 KB)

This line from the logs is the clue you are looking for:

17:17:58 WARN: Bytecode of dependencies was not provided for analysis of source files, you might end up with less precise results. Bytecode can be provided using sonar.java.libraries property.

To solve this problem (and avoid others), you should definitely consider using the scanner for maven that I linked in my previous post.

If not possible, you should make sure the project is correctly configured, by setting sonar.java.libraries property.

sonar.java.libraries: Comma-separated paths to files with third-party libraries (JAR or Zip files) used by your project.

You can have a look there for a similar problem.

Hope this helps,
Quentin

Thanks you very much!!!
This fixed our problem.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.