So, I have a multi-tiered Maven project. I'm using maven version 3.0.3 and Sonatype Nexus 2.0.3 hosted on Tomcat 6.0.24. The project builds (mvn clean install) cleanly, but mvn deploy fails on a random bundle halfway through. Deploying that bundle by hand also fails. I can use mvn deploy -rf :<next-bundle> and deploy the remainder of my artifacts, but that one bundle fails to upload. It also fails to upload if I do a mvn deploy on just that directory/project.
If I run mvn -X deploy, I get the following stack trace:
[DEBUG] Using connector WagonRepositoryConnector with priority 0 for http://nexushost:8080/nexus/content/repositories/my-snapshots/ as nexusadmin
Downloading: http://nexushost:8080/nexus/content/repositories/my-snapshots/my-toplevel/catalog/failing-project-name/1.2.0-SNAPSHOT/maven-metadata.xml
[WARNING] Could not transfer metadata my-toplevel.catalog:failing-project-name:1.2.0-SNAPSHOT/maven-metadata.xml from/to snapshots (http://nexushost:8080/nexus/content/repositories/my-snapshots/): Access denied to: http://nexushost:8080/nexus/content/repositories/my-snapshots/my-toplevel/catalog/failing-project-name/1.2.0-SNAPSHOT/maven-metadata.xml
org.sonatype.aether.transfer.MetadataTransferException: Could not transfer metadata my-toplevel.catalog:failing-project-name:1.2.0-SNAPSHOT/maven-metadata.xml from/to snapshots (http://nexushost:8080/nexus/content/repositories/my-snapshots/): Access denied to: http://nexushost:8080/nexus/content/repositories/my-snapshots/my-toplevel/catalog/failing-project-name/1.2.0-SNAPSHOT/maven-metadata.xml
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$3.wrap(WagonRepositoryConnector.java:932)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$3.wrap(WagonRepositoryConnector.java:923)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.flush(WagonRepositoryConnector.java:695)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.flush(WagonRepositoryConnector.java:689)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.get(WagonRepositoryConnector.java:445)
at org.sonatype.aether.impl.internal.DefaultDeployer.upload(DefaultDeployer.java:379)
at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:260)
at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:215)
at org.sonatype.aether.impl.internal.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:480)
at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:137)
at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:156)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
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:319)
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.wagon.authorization.AuthorizationException: Access denied to: http://nexushost:8080/nexus/content/repositories/my-snapshots/my-toplevel/catalog/failing-project-name/1.2.0-SNAPSHOT/maven-metadata.xml
at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:119)
at org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116)
at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88)
at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.run(WagonRepositoryConnector.java:608)
at org.sonatype.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:64)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
When this happens, exactly zero output is emitted to either the tomcat log ($tomcat_home/logs/catalina.out) or the Sonatype Nexus logs ($tomcat_home/sonatype-work/nexus/logs/nexus.log), even with Sonatype's log level set to DEBUG. The expected tree on the filesystem is totally empty, and the Tomcat user has full permissions on the entire sonatype-work tree. This behavior is consistent, even if I rename the bundle in question. If I rename a different project (one that uploads successfully via 'mvn deploy') to failing-project-name, it works. There aren't any obvious items in the POM that are different - it's basically identical to all my other POMS; I specify a few dependencies, and have build steps for cxf-codegen and maven-bundle-plugin.
Any thoughts? Any suggestions on how to even debug this?
Found it. I was being bitten by this bug:
https://issues.apache.org/jira/browse/CXF-4687
Certain versions of apache's cxf-codegen-plugin (including 2.6.2, the one I was using) mess with proxy settings. The reason I wasn't seeing any entry in the Nexus logs is because the proxy settings were keeping the request from even getting there.
Related
Recently (this morning) I stumbled across the following problem :
Jenkins build on one of my projects was failing.
I tried to make it work locally on my machine and was quite pleased (yet scared) to see it build seamlessly.
I, then, logged back to the jenkins machine to try to manually launch the mvn clean install and discovered that cute little error all over my build log.
[WARNING] Failed to read resolution tracking file /var/lib/jenkins/.m2/repository/local/org/apache/maven/plugins/maven-clean-plugin/2.4.1/_maven.repositories
java.io.IOException: Aucun verrou disponible
at sun.nio.ch.FileDispatcherImpl.lock0(Native Method)
at sun.nio.ch.FileDispatcherImpl.lock(FileDispatcherImpl.java:90)
at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1021)
at org.sonatype.aether.impl.internal.TrackingFileManager.lock(TrackingFileManager.java:203)
at org.sonatype.aether.impl.internal.TrackingFileManager.read(TrackingFileManager.java:58)
at org.sonatype.aether.impl.internal.EnhancedLocalRepositoryManager.readRepos(EnhancedLocalRepositoryManager.java:144)
at org.sonatype.aether.impl.internal.EnhancedLocalRepositoryManager.find(EnhancedLocalRepositoryManager.java:69)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:307)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:216)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:193)
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:281)
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:186)
at org.sonatype.aether.impl.internal.DefaultRepositorySystem.readArtifactDescriptor(DefaultRepositorySystem.java:279)
at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:115)
at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:142)
at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getMojoDescriptor(DefaultMavenPluginManager.java:261)
at org.apache.maven.plugin.DefaultBuildPluginManager.getMojoDescriptor(DefaultBuildPluginManager.java:185)
at org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.setupMojoExecution(DefaultLifecycleExecutionPlanCalculator.java:152)
at org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.setupMojoExecutions(DefaultLifecycleExecutionPlanCalculator.java:139)
at org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateExecutionPlan(DefaultLifecycleExecutionPlanCalculator.java:116)
at org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateExecutionPlan(DefaultLifecycleExecutionPlanCalculator.java:129)
at org.apache.maven.lifecycle.internal.BuilderCommon.resolveBuildPlan(BuilderCommon.java:92)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
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:606)
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)
Unfortunately I don't have the faintest idea of the reason why I get this.
My internet researches so far suggest that would be related to NFS somehow but :
I don't know the first thing on NFS
The person that could answer on the subject of the jenkins machine configuration is not anywhare around (and isn't likely to be anytime soon).
This is related to a bug: http://jira.codehaus.org/browse/MNG-5629
which is unresolved as at 2015-01-06. :(
Encounter this with the versions-maven-plugin also.
Just an FYI... I encountered similar issues when trying to build Maven Eclipse project (even when doing just the basic "Run As Maven Clean"). This seems to related to my U:\drive and the VPN.... I encountered the above problem when working from home using VPN access (ps. I can open up any files on my U: drive no problem). When I am working inside my company, then the problem doesn't come up.
My environment:
Windows 7 64bit
Eclipse Mars 4.5.2
with Maven Integration for Eclipse 1.6.2.20150902
U:\Profile.m2\settings.xml (my Maven settings.xml file is on local drive).
I installed Maven (3.3.9) and ran mvn clean successfully on the command line. This is consistently no matter even when I worked from home with the VPN access.
I'm using SVN, Maven 3.0.3 on the latest version of Jenkins and the Maven Release plugin. I'm trying to use the Maven release plugin (through Jenkins) do a dry run and so am executing the options …
Executing Maven: -B -f /scratch/jenkins/workspace/myproject/myproject/pom.xml -DdevelopmentVersion=53.0.0-SNAPSHOT -DreleaseVersion=52.0.0 -Dusername=***** -Dpassword=********* -DskipTests -P prod -Dresume=false -DdryRun=true release:prepare
But the dry run is dying with the error below …
[JENKINS] Archiving /scratch/jenkins/workspace/myproject/myproject/pom.xml to /home/evotext/hudson_home/jobs/myproject/modules/org.mainco.subco$myproject/builds/2013-11-18_16-09-14/archive/org.mainco.subco/myproject/52.0.0/myproject-52.0.0.pom
Waiting for Jenkins to finish collecting data
mavenExecutionResult exceptions not empty
message : Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.0:prepare (default-cli) on project myproject: You don't have a SNAPSHOT project in the reactor projects list.
cause : You don't have a SNAPSHOT project in the reactor projects list.
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.0:prepare (default-cli) on project myproject: You don't have a SNAPSHOT project in the reactor projects list.
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
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.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:117)
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:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:178)
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:606)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:129)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:67)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: org.apache.maven.plugin.MojoFailureException: You don't have a SNAPSHOT project in the reactor projects list.
at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:219)
at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:181)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 30 more
Caused by: org.apache.maven.shared.release.ReleaseFailureException: You don't have a SNAPSHOT project in the reactor projects list.
at org.apache.maven.shared.release.phase.CheckPomPhase.execute(CheckPomPhase.java:111)
at org.apache.maven.shared.release.phase.CheckPomPhase.simulate(CheckPomPhase.java:123)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:199)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140)
at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103)
at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:211)
... 33 more
My SVN checkout method is set to "Always checkout a fresh copy" and I have a snapshot version in question in my snapshot repository, but not in my release repository. Is there a way I can get the "reactor projects list" to look at my snapshot repo?
Edit: I'm including the snippet of my pom where the project gets its version -- it inherits it from a parent
<parent>
<artifactId>subco</artifactId>
<groupId>org.mainco.subco</groupId>
<version>52.0.0</version>
</parent>
You're trying to release an artifact that's not a snapshot. That means your artifact's version number is something like 3.0.3. That version number implies its already been released. You can't release a release. There would be no changes in between and therefore no point.
You're only supposed to release SNAPSHOT versions. That means your version number would be like 3.0.3-SNAPSHOT.
Jenkins workspace is not cleanup or you have FINAL version inside pom.xml. Jenkins has check-out strategy for cleaning up workspace.
More: Maven release plugin - SNAPSHOT project needed
Check-out Strategy options:
Emulate clean checkout by first deleting unversioned files/ignored files, as well as files/directories ignored by svn:ignore, then execute svn update.
Always check out fresh copy
Use svn update as much possible, with svn revert before update
Bump Up your Project POM file for from the previously built code base to a new version.
1.0.1-SNAPSHOT<version>1.0.1-SNAPSHOT</version>
Changing the check-out strategy to "Emulate clean checkout by first deleting unversioned files/ignored files, then svn update" did the trick for me.
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.
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
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.
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
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
SonarQube doesn't support the Maven '-pl' option, see https://jira.sonarsource.com/browse/SONAR-1742
When running the Maven Shade plugin, I get the following error. How can I debug this?
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:2.0:shade (make-shade) on project csprocessor-client: Error creating shaded jar: Unexpected end of ZLIB input stream -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:2.0:shade (make-shade) on project csprocessor-client: Error creating shaded jar: Unexpected end of ZLIB input stream
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
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:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
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:601)
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.MojoExecutionException: Error creating shaded jar: Unexpected end of ZLIB input stream
at org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:551)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.io.EOFException: Unexpected end of ZLIB input stream
at java.util.zip.ZipFile$ZipFileInflaterInputStream.fill(ZipFile.java:411)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158)
at java.io.FilterInputStream.read(FilterInputStream.java:107)
at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:188)
at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:174)
at org.apache.maven.plugins.shade.DefaultShader.addRemappedClass(DefaultShader.java:259)
at org.apache.maven.plugins.shade.DefaultShader.shade(DefaultShader.java:151)
at org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:484)
... 21 more
[ERROR]
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
It turns out that with the m2eclipse plugin, you can actually debug a maven plugin as it is executing. To do this you need to what code you want to step into, which you can do by setting the Debug Output option in the Maven Run Configuration. You'll also need to set the Resolve Workspace artifacts option.
With these two options I could click the file location listed in the error (ZipFile.java:411 in this case), set a break point, and use Debug As > Maven Build to run the Maven build in debug mode. Once the breakpoint was hit I could tell which file was causing the error, and repackage it using the JAR command. Even though the JAR file in question could be opened with a GUI archive tool, once repackaged with the JAR command I could successfully run the Maven Shade plgin.
FYI, if this was caused by a JAR that was corrupted during download, a quick way of forcing a re-download is to run mvn dependency:purge-local-repository in the shading project. This removes all dependencies (direct and transitive) of the project from the local Maven repository and downloads them anew.
I have written a Maven plugin abstractor, called maven-base-plugin. This plugin goes over all classes and resources and performs certain tasks. Since it is an abstract plugin, this plugin does not have its packaging set to maven-plugin, but rather "jar".
I have another plugin, tools-reporter, that using the above plugin API, creates reports for my project. Again, the reports and destinations for the reports are interfaces, so that they could be extended in future. Again, this project has a packaging of "jar".
Now, I have a third plugin, depending on the reporter plugin generating certain reports for use on artifacts and resources. This plugin has its packaging set to "maven-plugin". What's kept me stale for a while now, and various inspections have not solved it, is that I cannot build this third plugin successfully.
When I do, I get:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-plugin-plugin:2.3:descriptor (default-descriptor) on project tools-reporter-sample: Execution default-descriptor of goal org.apache.maven.plugins:maven-plugin-plugin:2.3:descriptor failed: 0 -> [Help 1]
The details say:
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-plugin-plugin:2.3:descriptor (default-descriptor) on project tools-reporter-sample: Execution default-descriptor of goal org.apache.maven.plugins:maven-plugin-plugin:2.3:descriptor failed: 0
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:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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)
at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-descriptor of goal org.apache.maven.plugins:maven-plugin-plugin:2.3:descriptor failed: 0
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 25 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.getJavaClass(JavaMojoDescriptorExtractor.java:534)
at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.execute(JavaMojoDescriptorExtractor.java:553)
at org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:84)
at org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(AbstractGeneratorMojo.java:135)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 26 more
Any help or insight would be much appreciated.
By the way, I have tried various combination of setting packaging to different values. The only thing that works is announcing the third plugin, tools-reporter-sample as a simple "jar", which is kind of counterproductive, since it eliminates the whole purpose of this exercise.
This is the gist to the offending code:
https://gist.github.com/3128364
Here is a description of what each of this is for:
AbstractPluginExecutor.java: The original base plugin that is bundled as a jar and is used by the basic reports plugin
mave-base-plugin-pom.xml: The pom.xml file for the base maven plugin
Executor.java: The abstract class that takes care of all the reporting goodness.
tools-reporter-pom.xml: The pom.xml file for the base report plugin.
Reporter.java: The sample plugin that is actually supposed to run.
tools-reporter-sample-pom.xml: The pom.xml file for the sample report plugin.
It turns out that the failure was not due to the plugins hierarchical design at all. But rather strangely, having the plugin include an annotation in its classpath did it. I had a class, #interface Sample {. Once I removed it, everything was solved.
I have not yet figured out why, though.