NPE in Jenkins/Maven analysis after upgrade to SonarQube 4.2

Question

After some time the analysis throws an NPE. But its not the first module it analyses. So I'm do not have a clue, what the problem might be. With SonarQube 4.1.2 it worked without a problem.

Here the logout of the NPE:

15:06:41 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.2:sonar (default-    cli) on project XXX: Can not execute SonarQube analysis
15:06:41    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
15:06:41    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
15:06:41    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
15:06:41    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
15:06:41    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
15:06:41    at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
15:06:41    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
15:06:41    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
15:06:41    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
15:06:41    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
15:06:41    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
15:06:41    at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
15:06:41    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
15:06:41    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
15:06:41    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
15:06:41    at java.lang.reflect.Method.invoke(Method.java:601)
15:06:41    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
15:06:41    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
15:06:41    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
15:06:41    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
15:06:41 Caused by: org.apache.maven.plugin.MojoExecutionException: Can not execute SonarQube analysis
15:06:41    at org.codehaus.mojo.sonar.Bootstraper.executeMojo(Bootstraper.java:109)
15:06:41    at org.codehaus.mojo.sonar.Bootstraper.start(Bootstraper.java:67)
15:06:41    at org.codehaus.mojo.sonar.SonarMojo.execute(SonarMojo.java:109)
15:06:41    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
15:06:41    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
15:06:41    ... 19 more
15:06:41 Caused by: org.apache.maven.plugin.MojoExecutionException
15:06:41    at org.sonar.maven.ExceptionHandling.handle(ExceptionHandling.java:37)
15:06:41    at org.sonar.maven.SonarMojo.execute(SonarMojo.java:175)
15:06:41    at org.codehaus.mojo.sonar.Bootstraper.executeMojo(Bootstraper.java:104)
15:06:41    ... 23 more
15:06:41 Caused by: java.lang.NullPointerException
15:06:41    at org.sonar.plugins.java.bridges.DsmSerializer.serializeCell(DsmSerializer.java:86)
15:06:41    at org.sonar.plugins.java.bridges.DsmSerializer.serializeRow(DsmSerializer.java:74)
15:06:41    at org.sonar.plugins.java.bridges.DsmSerializer.serializeRows(DsmSerializer.java:53)
15:06:41    at org.sonar.plugins.java.bridges.DsmSerializer.serialize(DsmSerializer.java:43)
15:06:41    at org.sonar.plugins.java.bridges.DsmSerializer.serialize(DsmSerializer.java:94)
15:06:41    at org.sonar.plugins.java.bridges.DesignBridge.serializeDsm(DesignBridge.java:133)
15:06:41    at org.sonar.plugins.java.bridges.DesignBridge.onProject(DesignBridge.java:83)
15:06:41    at org.sonar.plugins.java.Bridges.saveProject(Bridges.java:76)
15:06:41    at org.sonar.plugins.java.Bridges.save(Bridges.java:67)
15:06:41    at org.sonar.plugins.java.JavaSquidSensor.analyse(JavaSquidSensor.java:87)
15:06:41    at org.sonar.batch.phases.SensorsExecutor.executeSensor(SensorsExecutor.java:79)
15:06:41    at org.sonar.batch.phases.SensorsExecutor.execute(SensorsExecutor.java:70)
15:06:41    at org.sonar.batch.phases.PhaseExecutor.execute(PhaseExecutor.java:134)
15:06:41    at org.sonar.batch.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:186)
15:06:41    at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:92)
15:06:41    at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:77)
15:06:41    at org.sonar.batch.scan.ProjectScanContainer.scan(ProjectScanContainer.java:199)
15:06:41    at org.sonar.batch.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:194)
15:06:41    at org.sonar.batch.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:192)
15:06:41    at org.sonar.batch.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:192)
15:06:41    at org.sonar.batch.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:187)
15:06:41    at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:92)
15:06:41    at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:77)
15:06:41    at org.sonar.batch.scan.ScanTask.scan(ScanTask.java:56)
15:06:41    at org.sonar.batch.scan.ScanTask.execute(ScanTask.java:44)
15:06:41    at org.sonar.batch.bootstrap.TaskContainer.doAfterStart(TaskContainer.java:82)
15:06:41    at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:92)
15:06:41    at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:77)
15:06:41    at org.sonar.batch.bootstrap.BootstrapContainer.executeTask(BootstrapContainer.java:144)
15:06:41    at org.sonar.batch.bootstrap.BootstrapContainer.doAfterStart(BootstrapContainer.java:132)
15:06:41    at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:92)
15:06:41    at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:77)
15:06:41    at org.sonar.batch.bootstrapper.Batch.startBatch(Batch.java:92)
15:06:41    at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:74)
15:06:41    at org.sonar.runner.batch.IsolatedLauncher.execute(IsolatedLauncher.java:45)
15:06:41    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
15:06:41    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
15:06:41    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
15:06:41    at java.lang.reflect.Method.invoke(Method.java:601)
15:06:41    at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher.java:87)
15:06:41    at org.sonar.runner.impl.BatchLauncher$1.run(BatchLauncher.java:75)
15:06:41    at java.security.AccessController.doPrivileged(Native Method)
15:06:41    at org.sonar.runner.impl.BatchLauncher.doExecute(BatchLauncher.java:69)
15:06:41    at org.sonar.runner.impl.BatchLauncher.execute(BatchLauncher.java:50)
15:06:41    at org.sonar.runner.api.EmbeddedRunner.doExecute(EmbeddedRunner.java:102)
15:06:41    at org.sonar.runner.api.Runner.execute(Runner.java:90)
15:06:41    at org.sonar.maven.SonarMojo.execute(SonarMojo.java:173)
15:06:41    ... 24 more

Answer 1

JIRA ticket created : http://jira.codehaus.org/browse/SONARJAVA-501 with priority "Blocker"

Answer 2

Based on this thread it seems to be an issue of plugin not being up to date with SonarCube 4.2. It seems the changes are not backwards compatible.

Latest version of Jenkins plugin is 2.1. It was released in 2013, and since SonarCube 4.2 was just released a month ago, it would look like a new version of the plugin needs to be released for this to work.

Answer 3

Just for the record and to provide a more complete answer :

Issue is due to the fact that in one of the directory of your project some of your Java files define multiple packages :

directory  : foo 
                file A.java : 
                           package foo;
                           class A {.... 

                file B.java
                           package bar;
                           class B { .... 

This is totally supported by javac but it is a bad practice and it is detected by sonar-java analysis and raise the warning : "Directory contains files belonging to different packages - some metrics could be reported incorrectly: ..."

If the class B is referring some other classes of your project in another directory then it will raise the null pointer exception you are facing. The fix implemented in sonar-java 2.2 is to raise a specific exception in case you don't have a the skipDesign flag to fail the analysis and invite you either to fix the source code or to use the skipPackageDesign flag.

One question you might ask is why was that working prior to SQ 4.2 and sonar-java 2.1 : This was working because Java was a particular citizen of the SonarQube covered languages and used a specific Object called JavaPackage. We get rid of that particularity in SQ 4.2 and sonar-java 2.1 and so we are not able anymore to attach metrics correctly if you have multiple packages in one directory. And in the case you raised we even have trouble generating the dependency graph.

Solution is therefore to fix the code by putting files into the directories corresponding to their packages or to skip this dependency analysis using the flag already mentioned.

We provide a better error handling for this in upcoming sonar-java 2.2.