SonarQube upgrade from 6.4 to 6.5 breaks the scanner

11
votes
  1. I am on sonarQube6.4 and have upgraded to 6.5
  2. Sonar-scanner is 3.0.3
  3. Now after the upgrade the scanner fails anytime there is a java file in the source path. If I don't scan java files everything works just fine.
  4. However If I rollback an use 6.4 version, everything works fine, so is there any regression? This is the stack trace, when I run the scanner command with -X command. So is it a mandate in 6.5 to provided the location of all compiled classed, is there a way to ignore it.

04:56:21.218 DEBUG: Sensors : JavaSquidSensor -> SurefireSensor -> JaCoCoSensor -> SonarJavaXmlFileSensor -> Analyzer for "php.ini" files -> Zero Coverage Sensor -> CPD Block Indexer 04:56:21.218 INFO: Sensor JavaSquidSensor [java] 04:56:21.558 INFO: Configured Java source version (sonar.java.source): none 04:56:21.565 INFO: JavaClasspath initialization 04:56:21.570 INFO: ------------------------------------------------------------------------ 04:56:21.571 INFO: EXECUTION FAILURE 04:56:21.571 INFO: ------------------------------------------------------------------------ 04:56:21.571 INFO: Total time: 6.545s 04:56:21.707 INFO: Final Memory: 51M/1083M 04:56:21.707 INFO: ------------------------------------------------------------------------ 04:56:21.707 ERROR: Error during SonarQube Scanner execution org.sonar.squidbridge.api.AnalysisException: Please provide compiled classes of your project with sonar.java.binaries property at org.sonar.java.JavaClasspath.init(JavaClasspath.java:59) at org.sonar.java.AbstractJavaClasspath.getElements(AbstractJavaClasspath.java:281) at org.sonar.java.SonarComponents.getJavaClasspath(SonarComponents.java:141) at org.sonar.java.JavaSquid.(JavaSquid.java:83) at org.sonar.plugins.java.JavaSquidSensor.execute(JavaSquidSensor.java:83) at org.sonar.scanner.sensor.SensorWrapper.analyse(SensorWrapper.java:53) at org.sonar.scanner.phases.SensorsExecutor.executeSensor(SensorsExecutor.java:88) at org.sonar.scanner.phases.SensorsExecutor.execute(SensorsExecutor.java:82) at org.sonar.scanner.phases.SensorsExecutor.execute(SensorsExecutor.java:68) at org.sonar.scanner.phases.AbstractPhaseExecutor.execute(AbstractPhaseExecutor.java:78) at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:179) at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:144) at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:129) at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:261) at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:256) at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:245) at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:144) at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:129) at org.sonar.scanner.task.ScanTask.execute(ScanTask.java:47) at org.sonar.scanner.task.TaskContainer.doAfterStart(TaskContainer.java:84) at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:144) at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:129) at org.sonar.scanner.bootstrap.GlobalContainer.executeTask(GlobalContainer.java:119) at org.sonar.batch.bootstrapper.Batch.executeTask(Batch.java:116) at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60) at com.sun.proxy.$Proxy0.execute(Unknown Source) at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:233) at org.sonarsource.scanner.api.EmbeddedScanner.runAnalysis(EmbeddedScanner.java:151) at org.sonarsource.scanner.cli.Main.runAnalysis(Main.java:123) at org.sonarsource.scanner.cli.Main.execute(Main.java:77) at org.sonarsource.scanner.cli.Main.main(Main.java:61) 04:56:21.710 DEBUG: Execution getVersion 04:56:21.711 DEBUG: Execution stop

When I run the same with 6.4, it works fine and the only warning I see in the console is :

04:52:42.738 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

4
sonarqubesonarqube-scan
The plugin version is important, seems your two SonarQube might run a different SonarJava version. – Nicolas B. - SonarSource Team
Agreed, in 6.4 it is sonar-java-plugin-4.9.0.9858.jar, while in 6.5 it is sonar-java-plugin-4.12.0.11033.jar, but still I believe this is a regression, where with the new plugin it is a mandate to provide the .class files location. I wish there is an option to override it – Prashant Saddi

4 Answers

22
votes

Error during SonarQube Scanner execution org.sonar.squidbridge.api.AnalysisException: Please provide compiled classes of your project with sonar.java.binaries property

Since SonarJava 4.12, you must specify sonar.java.binaries property https://docs.sonarqube.org/display/PLUG/Java+Plugin+and+Bytecode

Example :

sonar-scanner -Dsonar.projectKey=fr.demo:my-project -Dsonar.sources=. -Dsonar.java.binaries=.
1
votes

The error message says:

Error during SonarQube Scanner execution org.sonar.squidbridge.api.AnalysisException:
Please provide compiled classes of your project with sonar.java.binaries property

It seems like the java sensor requires the .class files, in addition to the .java files.

You could:

  • Add those files to the analysis (it will by the way give you more valuable sonar findings!)
  • Try adding and removing files to find out, which piece of code causes the issue and report it as a Sonar Java bug
1
votes

I had this issue as well and I fixed it in the following way:

This page mentions about an entry which was optional before and became mandatory during the latest update (4.12). It says that the sonar.java.binaries entry in the Jenkins project settings should be set. When set, even to a faulty folder, it will fix your errors, leaving only a warning and your pipeline will be running again.

The setting should be added to Jenkins -> "your project" -> Configuration -> Build -> Execute SonarQube Scanner -> Analysis Properties. Add this entry and point it to your binaries folder.

0
votes

Even i was also facing same issue after SonarQube upgrade to latest 6.5 version. But after downgrading SonarJava plugin(from 4.12 to 4.11), it worked. Hope it will help you.