versions used (SonarQube, Scanner, Plugin, and any relevant extension)
Not really usefull as the problem can be reproduced with a test (see below)
SonarQube Community Edition Version 7.5 (build 20543)
sonar-maven-plugin 3.6.0.1398
The most revelant :
java-frontend 5.10.1.16922 (also tried with 5.10.2.17019)
error observed (wrap logs/code around triple quote ``` for proper formatting)
org.sonar.plugins.java.api.semantic.Symbol.type() returns null because of org.sonar.plugins.java.api.tree.MethodInvocationTree.symbol() returning !unknownSymbol!
Import the project in your prefered editor (I used Eclipse)
Run the test named org.test.testy.NoBigDecimalRuleTest
Test should success
Move the “Entity” class for src/test/java to src/main/java
Run the test again
Test should fail because of the raised IllegalStateException
That’s the same if you move the class to a dependency, which is the problem I encounter in some production code, but it’s more painfull to use a dependency within a test.
this is expected behavior, unit test framework consider only single file for the analysis, and will not automatically pick up other files. You can provide compiled class file as part of the classpath using the overload org.sonar.java.se.JavaCheckVerifier#verify(java.lang.String, org.sonar.plugins.java.api.JavaFileScanner, java.util.Collection<java.io.File>) if you want to test behavior of the rule with specific classes available on the classpath.
Now you might be surprised why does this work when class is in test directory, the reason for this is that sonar-java will use the classpath of the jvm running the test itself, and you will have the Entity class available there, because IDE will provide it on the classpath.
If you see this happening in the production, most likely the analysis is misconfigured and sonar.java.libraries is not set correctly. Anyway good strategy for writing rules is always check returned value, because analysis can be configured incorrectly.
Thanks for your reply.
You’re right and I maybe tried to simplify the problem too much : unit test isn’t as revelant as I expected.
However I still have an equivalent problem with analysis on production code.
As I exposed earlier, I use sonar-maven-plugin 3.6.0.1398.
This plugin should set sonar.java.libraries correctly, doesn’t it ? (assuming dependency is declared at scope ‘compile’)
I’ll try to give you a more representative repository as soon as I can :
a project containing a similar rule (to add to a SonarQube)
a project which can be considered as “production” project