SonarQube 3.7 with maven and Jenkins - Maven session does not declare a top level project

Question

Context

I'm currently having an issue with sonarqube 3.7 being run by maven via jenkins

The project is setup as a maven multi-module project and jenkins is running sonar (via maven) using the following param: "-pl "

I have updated "sonar" 3.6 to "sonarqube" 3.7 and also "sonar-maven-plugin" to 3.7

Problem

Since the update I see the following error in jenkins (1.529):

[ERROR] Failed to execute goal org.codehaus.sonar:sonar-maven-plugin:3.7:sonar (default-cli) on project xxxxx: Execution default-cli of goal org.codehaus.sonar:sonar-maven-plugin:3.7:sonar failed: Unable to execute Sonar: Maven session does not declare a top level project -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.sonar:sonar-maven-plugin:3.7:sonar (default-cli) on project xxxxx: Execution default-cli of goal org.codehaus.sonar:sonar-maven-plugin:3.7:sonar failed: Unable to execute Sonar
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:616)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-cli of goal org.codehaus.sonar:sonar-maven-plugin:3.7:sonar failed: Unable to execute Sonar
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
    ... 19 more
Caused by: 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:90)
    at org.sonar.maven.SonarMojo.execute(SonarMojo.java:172)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
    ... 20 more
Caused by: java.lang.IllegalStateException: Maven session does not declare a top level project
    at org.sonar.plugins.maven.MavenProjectBootstrapper.bootstrap(MavenProjectBootstrapper.java:53)
    at org.sonar.batch.scan.ProjectScanContainer.projectBootstrap(ProjectScanContainer.java:104)
    at org.sonar.batch.scan.ProjectScanContainer.doBeforeStart(ProjectScanContainer.java:82)
    at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:86)
    at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:73)
    at org.sonar.batch.scan.ScanTask.scan(ScanTask.java:57)
    at org.sonar.batch.scan.ScanTask.execute(ScanTask.java:45)
    at org.sonar.batch.bootstrap.TaskContainer.doAfterStart(TaskContainer.java:82)
    at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:88)
    at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:73)
    at org.sonar.batch.bootstrap.BootstrapContainer.executeTask(BootstrapContainer.java:156)
    at org.sonar.batch.bootstrap.BootstrapContainer.doAfterStart(BootstrapContainer.java:144)
    at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:88)
    at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:73)
    at org.sonar.batch.bootstrapper.Batch.startBatch(Batch.java:92)
    at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:74)
    at org.sonar.runner.batch.IsolatedLauncher.execute(IsolatedLauncher.java:45)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:616)
    at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher.java:87)
    ... 28 more

Expected behavior

sonar should check the code as it did with the previous version

Alternative solution

If I do not use the -pl param (it works only if I delete the project in sonarqube)

But I would still like to only run sonar on a specific module.

Answer 1

You are running into what a lot of us heavy SonarQube users find on a regular basis: any off-nominal techniques to invoke SonarQube will break during some eventual upgrade. We're so used to it at work that we simply bake in the time to remediate upgrade issues into the cost of a SonarQube upgrade.

I don't doubt that -pl worked in the past. But as SonarQube continues to work against many languages, it will shed its roots as a Java- and Maven-only continuous inspection tool.

SonarQube is happiest when you're invoking it as a plain-jane mvn sonar:sonar. You should specify additional SonarQube configuration in your multimodule parent POM, because that's the only guaranteed means by which an altered configuration will be honored, now and in the future.

If you just want to run SonarQube against one module, set sonar.includedModules to include only the multimodule parent as well as the target module. So if your multimodule parent's <artifactId> is foo-parent and your desired module is foo-module, you need to set the following property in foo-parent's POM:

sonar.includedModules=foo-parent,foo-module

Answer 2

I had the same issue when I'm trying to run sonar through command like :- sonar:sonar -pl moduleA where it was looking for parent module, So I've tried this & it worked with :- sonar:sonar -pl .,moduleA. This will build only one specific project in multi-module maven project & as we've specified "." it would build parent pom which resolved the issue.

Answer 3

sonar.includedModules are deprecated since 4.3

https://docs.sonarqube.org/display/SONARQUBE53/Release+4.3+Upgrade+Notes

The sonar.skippedModules and sonar.includedModules properties are deprecated. They should be replaced by standards Maven advanced reactor options. For example, let's say that you have the following multi-module project:

 org.mycompany:my-project
     - moduleA (org.mycompany:module-A)
     - moduleB (org.mycompany:module-B)
     - moduleC (org.mycompany:module-C)

Then

mvn sonar:sonar -Dsonar.skippedModules=module-B 

should be replaced (since Maven 3.2.1) by

mvn sonar:sonar -pl !moduleB

Answer 4

I know this is a bit old question, but what helped me on this case of using the -pl option was to use the opposite logic. Instead of passing the modules you want to execute the analysis you should pass the modules you don't want to analyze instead. For example, if you have 4 modules and just want to analyze the third one, you -pl you look like this:

-pl !module1,!module2,!module4

Answer 5

SonarQube doesn't support the Maven '-pl' option, see https://jira.sonarsource.com/browse/SONAR-1742