11
  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

TT.
  • 15,774
  • 6
  • 47
  • 88
Prashant Saddi
  • 111
  • 1
  • 1
  • 3
  • The plugin version is important, seems your two SonarQube might run a different SonarJava version. – Nicolas B. Aug 21 '17 at 07:39
  • 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 Aug 21 '17 at 16:02

4 Answers4

22

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=.
gujou
  • 416
  • 2
  • 6
  • what did you provide the java.binaries as for android project? – Emjey Apr 04 '19 at 12:45
  • @Mrityunjeyan S : you can find an example here : https://android.jlelse.eu/sonarqube-code-coverage-for-kotlin-on-android-with-bitrise-71b2fee0b797 "sonar.sources=app/src/main/java" "sonar.java.binaries=target/classes" If you execute sonar-scanner, the arguments are "-Dsonar.sources=app/src/main/java" and "-Dsonar.java.binaries=target/classes" Adapt the path according to your own application path. – gujou Apr 28 '19 at 17:52
1

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
slartidan
  • 20,403
  • 15
  • 83
  • 131
  • Hi, Thanks for your time. I agree, the analysis results would be more accurate with the bytecode access. However the fact is we don't version control the class files in GIT, so when we invoke this as a simple trigger with version control, there is no access to these .classes and hence it breaks now, unlike in 6.4 – Prashant Saddi Aug 21 '17 at 16:26
  • @PrashantSaddi Could you run the analysis on the same machine that runs the compilation of your code? – slartidan Aug 22 '17 at 07:45
  • I am actually trying to use SQ as part of jenkins builds so it depends on how the users have setup their sonar properties. I am very sure they don't have this property, so requesting 100 different teams to make changes to their jobs might not be easy, so maybe we wait for a future version which allows the binaries location to be optional – Prashant Saddi Aug 22 '17 at 19:00
1

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.

Mustafa Özçetin
  • 1,893
  • 1
  • 14
  • 16
Adrian vdBoom
  • 83
  • 1
  • 7
0

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.

Prateek Naik
  • 2,522
  • 4
  • 18
  • 38