SonarQube 3.7 con Maven e Jenkins - sessione di Maven non dichiara un progetto di livello superiore

Question

Contesto

Attualmente sto avendo un problema con il sonarqube 3.7 viene gestita da Maven via Jenkins

Il progetto è configurato come progetto multi-modulo di maven e jenkins esegue il sonar (via Maven) usando il seguente parametro: "-pl"

Ho aggiornato "sonar" da 3.6 a "sonarqube" 3.7 e anche "sonar-maven-plugin" a 3.7

Problema

Dal momento che l'aggiornamento vedo il seguente errore nel 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 

Comportamento previsto

sonar dovrebbe controllare il codice come ha fatto con la precedente versione

Soluzione alternativa

Se io non uso il parametro -pl (funziona solo se si elimina il progetto in sonarqube)

Ma mi piace ancora di essere eseguito solo il sonar su un modulo specifico.

Answer 1

Si esegue in quello che molti di noi pesanti utenti SonarQube trova su base regolare: qualsiasi off-nominali tecniche per invocare SonarQube sostituirà durante l'eventuale aggiornamento. Ci siamo così abituati al lavoro che dobbiamo semplicemente fare in tempo per rimediare ai problemi di aggiornamento nel costo di un aggiornamento SonarQube.

Non dubito che -pl abbia funzionato in passato. Ma con SonarQube che continua a funzionare con molte lingue, diventerà la sua radice come strumento di ispezione continua solo per Java e Maven.

SonarQube è più felice quando lo invochi come un piano-jane mvn sonar:sonar. Dovresti specificare una configurazione SonarQube aggiuntiva nel tuo POM genitore multimodule, perché questo è l'unico mezzo garantito per cui una configurazione modificata sarà onorato, ora e in futuro.

Se si desidera eseguire SonarQube su un modulo, impostare sonar.includedModules per includere solo il genitore multimodule e il modulo di destinazione. Quindi, se del <artifactId> vostro genitore multimodulo è foo-parent e il modulo desiderato è foo-modulo, è necessario impostare la seguente proprietà in foo-parent 's POM:

sonar.includedModules=foo-parent,foo-module

Answer 2

SonarQube non supporta l'opzione Maven '-pl', vedi http://jira.codehaus.org/browse/SONAR-1742

Answer 3

sonar .includedModules sono deprecati dal 4.3

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

Le sonar.skippedModules e le proprietà sonar.includedModules sono obsoleti. Dovrebbero essere sostituiti da standard Maven opzioni avanzate del reattore. Per esempio, diciamo che avete il seguente progetto di multi-modulo:

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

Poi

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

deve essere sostituito (dal Maven 3.2.1) per

mvn sonar:sonar -pl !moduleB 

Answer 4

So che questa è una domanda un po 'vecchia, ma cosa mi ha aiutato in questo caso di utilizzare l'opzione -pl era utilizzare la logica opposta. Invece di passare i moduli su cui vuoi eseguire l'analisi, devi invece passare i moduli che non vuoi analizzare. Ad esempio, se si dispone di 4 moduli e vogliono solo per analizzare la terza, è -pl si guarda in questo modo:

-pl !module1,!module2,!module4