Invalid value for sonar.java.binaries for multi module maven project

[voni...@googlemail.com]

I have a simple multi module maven project with the following structure:

+ my-project (sourcecode)
+ my-project-st(only junit integration tests)
pom.xml (parent pom)
sonar-project.properties (sonar.java.binaries=target/classes)

I build the project with Jenkins 1625.3 with SonarQube PlugIn 2.3 and SonarQube Runner 2.4 to build the project. 

The SonarQube server runs SonarQube 5.3 with Java Plugin 3.9

When I build the project with Standalone Sonarqube Analysis, I get the following error:

08:00:52.128 INFO  - Quality profile for java: Sonar way
08:00:52.138 INFO  - Sensor JavaSquidSensor
08:00:52.140 INFO  - Configured Java source version: none
08:00:52.206 ERROR - Invalid value for sonar.java.binaries
INFO: ------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
Total time: 12.045s
Final Memory: 11M/215M
INFO: ------------------------------------------------------------------------
ERROR: Error during Sonar runner execution
org.sonar.runner.impl.RunnerException: Unable to execute Sonar
        at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher.java:91)
        at org.sonar.runner.impl.BatchLauncher$1.run(BatchLauncher.java:75)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.sonar.runner.impl.BatchLauncher.doExecute(BatchLauncher.java:69)
        at org.sonar.runner.impl.BatchLauncher.execute(BatchLauncher.java:50)
        at org.sonar.runner.api.EmbeddedRunner.doExecute(EmbeddedRunner.java:102)
        at org.sonar.runner.api.Runner.execute(Runner.java:100)
        at org.sonar.runner.Main.executeTask(Main.java:70)
        at org.sonar.runner.Main.execute(Main.java:59)
        at org.sonar.runner.Main.main(Main.java:53)
Caused by: java.lang.IllegalStateException: No files nor directories matching 'target/classes'
        at org.sonar.java.AbstractJavaClasspath.getFilesFromProperty(AbstractJavaClasspath.java:88)
        at org.sonar.java.JavaClasspath.init(JavaClasspath.java:46)
        at org.sonar.java.AbstractJavaClasspath.getElements(AbstractJavaClasspath.java:170)
        at org.sonar.java.SonarComponents.getJavaClasspath(SonarComponents.java:126)
        at org.sonar.java.JavaSquid.<init>(JavaSquid.java:87)
        at org.sonar.plugins.java.JavaSquidSensor.analyse(JavaSquidSensor.java:89)
        at org.sonar.batch.phases.SensorsExecutor.executeSensor(SensorsExecutor.java:58)
        at org.sonar.batch.phases.SensorsExecutor.execute(SensorsExecutor.java:50)
        at org.sonar.batch.phases.PhaseExecutor.execute(PhaseExecutor.java:98)
        at org.sonar.batch.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:185)
        at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:132)
        at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:117)
        at org.sonar.batch.scan.ProjectScanContainer.scan(ProjectScanContainer.java:243)
        at org.sonar.batch.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:238)
        at org.sonar.batch.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:236)
        at org.sonar.batch.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:228)
        at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:132)
        at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:117)
        at org.sonar.batch.task.ScanTask.execute(ScanTask.java:55)
        at org.sonar.batch.task.TaskContainer.doAfterStart(TaskContainer.java:86)
        at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:132)
        at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:117)
        at org.sonar.batch.bootstrap.GlobalContainer.executeTask(GlobalContainer.java:122)
        at org.sonar.batch.bootstrapper.Batch.executeTask(Batch.java:119)
        at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:79)
        at org.sonar.runner.batch.IsolatedLauncher.execute(IsolatedLauncher.java:48)
        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:497)
        at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher.java:87)
        ... 9 more
ERROR: 
ERROR: Re-run SonarQube Runner using the -X switch to enable full debug logging.
Build step 'Invoke Standalone SonarQube Analysis' marked build as failure
Finished: FAILURE

I already found this issue: https://jira.sonarsource.com/browse/SONARJAVA-878, but it is more related to maven plugin and closed. 

I think it would be better to pickup only the test results (JaCoCo) from projects with no source files, but not to produce an error. 

Regards,
Simon

[Duarte Meneses]

Hi,

Did you build the project before running the analysis?

...

[voni...@googlemail.com]

Yes, SonarQube is only a POST Build step after successful execution of mvn clean install

[Duarte Meneses]

Can you please try to use sonar maven plugin instead of sonar-runner?
The parent module (which has no target) should be properly handled when using the maven plugin.

[voni...@googlemail.com]

The maven plugin runs fine, however it says that "It is no longer recommended to use SonarQube maven builder. It is preferable to set up SonarQube in the build environment and use a standard Jenkins maven target." 

The problem is not (only) the parent pom without target, but also the "my-project-st", which contains only tests and will not create a "target/classes", but only "target/test-classes" on build. 

Is there any plan to fix this for a upcoming version when using standalone runner?

[voni...@googlemail.com]

Update: it is only about the "my-project-st". If I add a simple Java source file "Dummy.java" the analysis works fine also with standalone runner. 

[Duarte Meneses]

As the message suggests, it is preferable to inject the SonarQube configuration in the build as environment variables, and then using them in a standard maven job.
An example is given in the doc.

Using maven, the analyser is able to properly handle parent modules and to automatically find the resources using maven's configuration (pom files).
If that's not the case, please let me know.

With sonar-runner, you would need to explicitly configure the location of certain resources, such as bytecode, using properties for each module, when they are not located in the default location. This behaviour won't change.