We are using SonarQube Server 184.108.40.206497 Community Edition for analyzing our code base. Since a couple of years now, we also develop custom java rule, extending the sonar java plugin. As we are considering migrating to the latest SonarQube Server verion 9.7, I’m currently migrating our 53 custom java rules to the new Sonarqube plugin API version an Sonar Java Plugin version.
So, I am migrating the following dependencies in our pom.xml:
Sonar Java Plugin
|Dependency||Old Version||New Version|
|Sonar Java Plugin||org.sonarsource.java:sonar-java-plugin:220.127.116.1138||org.sonarsource.java:sonar-java-plugin:18.104.22.168229|
|Sonar Plugin API Impl||org.sonarsource.sonarqube:sonar-plugin-api-impl:22.214.171.124497||org.sonarsource.sonarqube:sonar-plugin-api-impl:126.96.36.199563|
|Sonar Plugin API||org.sonarsource.sonarqube:sonar-plugin-api:188.8.131.52497||org.sonarsource.api.plugin:sonar-plugin-api:184.108.40.2060
NB: new group id for sonar plugin api and different versions betwenn api implementation and api!
After migration my Sonar plugin workspace to the new versions, I encounter the problem, that for some of my test classes - the classes that are analyzed by the rules - no TypeSymbols are available anymore. This causes a failure of the tests which rely on these symbol information:
Debugging the execution I found the following differences:
I didn’t change anything else. The test classes are in the same workspace under the folder “src/test/java” and are compiled during the build process. The class files should be available, when running the tests as in other cases, the symbol is not unknown.
In the example above, I’m trying to evaluate a method call on a method defined in a super class. Maybe the problem lies in this constellation, but I can’t imagine why.
Any help would be appreciated!