[jira] (MPDF-65) Not able to generate PDF reports from sonar
[ https://jira.codehaus.org/browse/MPDF-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=351933#comment-351933 ] Sonam Varma commented on MPDF-65: - Hi , I have put the PDF plugin in the sonar folder, then restarted the sonarqube server. Also made changes in the Configuration settings still I am not able to generate the PDF reports from the SONAR WEB interface. Could you please help me out. I would like to know what steps are needed to generate the PDF reports. Its of utmost importance to me. Please HELP !! Not able to generate PDF reports from sonar --- Key: MPDF-65 URL: https://jira.codehaus.org/browse/MPDF-65 Project: Maven PDF Plugin Issue Type: Bug Reporter: Sonam Varma Hi , I have put the PDF plugin in the sonar folder, then restarted the sonarqube server. Also made changes in the Configuration settings still I am not able to generate the PDF reports from the SONAR WEB interface. Could you please help me out. I would like to know what steps are needed to generate the PDF reports. Its of utmost importance to me. Please HELP !! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEPLOY-180) deploy:deploy with maven-deploy-plugin:2.7:deploy
[ https://jira.codehaus.org/browse/MDEPLOY-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MDEPLOY-180. --- Resolution: Not A Bug Assignee: Karl-Heinz Marbaise Unfortunately no feedback has been received so i will close this issue. If you will add the feedback etc. don't hesitate to reopen the issue. deploy:deploy with maven-deploy-plugin:2.7:deploy - Key: MDEPLOY-180 URL: https://jira.codehaus.org/browse/MDEPLOY-180 Project: Maven Deploy Plugin Issue Type: Bug Affects Versions: 2.7 Environment: Window 7 64bit + Eclipse Kepler Reporter: Martin Spamer Assignee: Karl-Heinz Marbaise Priority: Critical Upgrade to {{org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy}} results in critical failure when issuing {{deploy:deploy}}. {noformat} [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-cli) on project who-test-core: The packaging for this project did not assign a file to the build artifact - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-cli) on project who-test-core: The packaging for this project did not assign a file to the build artifact at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216) 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:317) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) 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:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) at org.codehaus.classworlds.Launcher.main(Launcher.java:46) Caused by: org.apache.maven.plugin.MojoExecutionException: The packaging for this project did not assign a file to the build artifact at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:180) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) ... 20 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 {noformat} -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEPLOY-178) Use information provided in pom.xml of JAR
[ https://jira.codehaus.org/browse/MDEPLOY-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=351936#comment-351936 ] Karl-Heinz Marbaise commented on MDEPLOY-178: - This patch looks good so far so good but it would be great if you can create an appropriate test case for that. Use information provided in pom.xml of JAR -- Key: MDEPLOY-178 URL: https://jira.codehaus.org/browse/MDEPLOY-178 Project: Maven Deploy Plugin Issue Type: New Feature Components: deploy:deploy-file Affects Versions: 2.8.1 Reporter: Dominik Schmucki Priority: Minor Attachments: DeployFileMojo-usePomInJar.patch We need to upload several third-party JARs to our repository. All we have is the JARs (which were built by Maven). The maven-install-plugin has a feature which allows to use the information (groupId, artifactId, version) from the packaged pom.xml. Adding this feature to the maven-deploy-plugin would allow us to simplify the maintenance of our repository. The attached patch is based on the maven-install-plugin. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPDF-65) Not able to generate PDF reports from sonar
[ https://jira.codehaus.org/browse/MPDF-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MPDF-65. -- Resolution: Not A Bug Assignee: Robert Scholte You're confusing the maven-pdf-plugin with the [SonarQube PDF plugin|http://docs.codehaus.org/display/SONAR/PDF+Plugin] Not able to generate PDF reports from sonar --- Key: MPDF-65 URL: https://jira.codehaus.org/browse/MPDF-65 Project: Maven PDF Plugin Issue Type: Bug Reporter: Sonam Varma Assignee: Robert Scholte Hi , I have put the PDF plugin in the sonar folder, then restarted the sonarqube server. Also made changes in the Configuration settings still I am not able to generate the PDF reports from the SONAR WEB interface. Could you please help me out. I would like to know what steps are needed to generate the PDF reports. Its of utmost importance to me. Please HELP !! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5562) Upgrade Aether 1.0 when available
[ https://jira.codehaus.org/browse/MNG-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5562. --- Resolution: Fixed Fix Version/s: 3.2.4 Upgrade Aether 1.0 when available - Key: MNG-5562 URL: https://jira.codehaus.org/browse/MNG-5562 Project: Maven Issue Type: Task Components: Artifacts and Repositories Affects Versions: 3.0.4, 3.0.5, 3.1.0-alpha-1, 3.1.0, 3.1.1 Reporter: Robert Scholte Assignee: Igor Fedorenko Priority: Minor Fix For: 3.2.4 Attachments: aether-upgrade.patch Aether-0.9.0-M4 fixes a couple of issues, for instance MDEP-405/MNG-5366 Upgrading is a bit tricky due to changed artifacts, see http://wiki.eclipse.org/Aether/New_and_Noteworthy#Transporters The attached patch contains the upgrade. Jason advises to wait for Aether-1.0, which should be coming Real Soon (tm) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5562) Upgrade Aether 1.0 when available
[ https://jira.codehaus.org/browse/MNG-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko reassigned MNG-5562: --- Assignee: Igor Fedorenko Upgrade Aether 1.0 when available - Key: MNG-5562 URL: https://jira.codehaus.org/browse/MNG-5562 Project: Maven Issue Type: Task Components: Artifacts and Repositories Affects Versions: 3.0.4, 3.0.5, 3.1.0-alpha-1, 3.1.0, 3.1.1 Reporter: Robert Scholte Assignee: Igor Fedorenko Priority: Minor Fix For: 3.2.4 Attachments: aether-upgrade.patch Aether-0.9.0-M4 fixes a couple of issues, for instance MDEP-405/MNG-5366 Upgrading is a bit tricky due to changed artifacts, see http://wiki.eclipse.org/Aether/New_and_Noteworthy#Transporters The attached patch contains the upgrade. Jason advises to wait for Aether-1.0, which should be coming Real Soon (tm) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5592) Maven Dependency Resolution Locks up
[ https://jira.codehaus.org/browse/MNG-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko reassigned MNG-5592: --- Assignee: Igor Fedorenko Maven Dependency Resolution Locks up Key: MNG-5592 URL: https://jira.codehaus.org/browse/MNG-5592 Project: Maven Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.1.1, 3.2.1 Environment: OS/X, Java 7 and Java 8 Reporter: Mark Derricutt Assignee: Igor Fedorenko Fix For: 3.2.4 Attachments: mng-5592-simplified.zip, mng-5592.zip, MNG-5592.zip One one of my larger integration projects that involves A LOT of version ranges across a broad range of dependencies I'm seeing that Maven locks up resolving dependencies. I've recently seen this in 3.1.1 but it's happening more and more often under 3.2.1. It appears that Eclipse Aether is falling into a circular loop somewhere and locking up. {code} main #1 prio=5 os_prio=31 tid=0x7f966b001000 nid=0x1903 runnable [0x000103559000] java.lang.Thread.State: RUNNABLE at org.eclipse.aether.util.graph.transformer.ConflictResolver$ConflictContext.isIncluded(ConflictResolver.java:1062) at org.eclipse.aether.util.graph.transformer.NearestVersionSelector$1.accept(NearestVersionSelector.java:145) at org.eclipse.aether.util.graph.visitor.PathRecordingDependencyVisitor.visitEnter(PathRecordingDependencyVisitor.java:88) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:324) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.util.graph.transformer.NearestVersionSelector.newFailure(NearestVersionSelector.java:149) at org.eclipse.aether.util.graph.transformer.NearestVersionSelector.backtrack(NearestVersionSelector.java:111) at org.eclipse.aether.util.graph.transformer.NearestVersionSelector.selectVersion(NearestVersionSelector.java:84) at org.eclipse.aether.util.graph.transformer.ConflictResolver.transformGraph(ConflictResolver.java:187) at org.eclipse.aether.internal.impl.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:275) at org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:317) at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:159) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:195) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127) at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:257) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:200) 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:108) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116) at
[jira] (MNG-5592) Maven Dependency Resolution Locks up
[ https://jira.codehaus.org/browse/MNG-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5592. --- Resolution: Fixed Fix Version/s: 3.2.4 Fixed by upgrading to aether 1.0 https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=2909b5a329fd946796428a8e7f46034bc3bcbd2f Maven Dependency Resolution Locks up Key: MNG-5592 URL: https://jira.codehaus.org/browse/MNG-5592 Project: Maven Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.1.1, 3.2.1 Environment: OS/X, Java 7 and Java 8 Reporter: Mark Derricutt Assignee: Igor Fedorenko Fix For: 3.2.4 Attachments: mng-5592-simplified.zip, mng-5592.zip, MNG-5592.zip One one of my larger integration projects that involves A LOT of version ranges across a broad range of dependencies I'm seeing that Maven locks up resolving dependencies. I've recently seen this in 3.1.1 but it's happening more and more often under 3.2.1. It appears that Eclipse Aether is falling into a circular loop somewhere and locking up. {code} main #1 prio=5 os_prio=31 tid=0x7f966b001000 nid=0x1903 runnable [0x000103559000] java.lang.Thread.State: RUNNABLE at org.eclipse.aether.util.graph.transformer.ConflictResolver$ConflictContext.isIncluded(ConflictResolver.java:1062) at org.eclipse.aether.util.graph.transformer.NearestVersionSelector$1.accept(NearestVersionSelector.java:145) at org.eclipse.aether.util.graph.visitor.PathRecordingDependencyVisitor.visitEnter(PathRecordingDependencyVisitor.java:88) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:324) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.util.graph.transformer.NearestVersionSelector.newFailure(NearestVersionSelector.java:149) at org.eclipse.aether.util.graph.transformer.NearestVersionSelector.backtrack(NearestVersionSelector.java:111) at org.eclipse.aether.util.graph.transformer.NearestVersionSelector.selectVersion(NearestVersionSelector.java:84) at org.eclipse.aether.util.graph.transformer.ConflictResolver.transformGraph(ConflictResolver.java:187) at org.eclipse.aether.internal.impl.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:275) at org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:317) at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:159) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:195) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127) at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:257) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:200) 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:108) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76) at
[jira] (MNG-5562) Upgrade Aether 1.0 when available
[ https://jira.codehaus.org/browse/MNG-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=351951#comment-351951 ] Igor Fedorenko commented on MNG-5562: - Implemented in https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=2909b5a329fd946796428a8e7f46034bc3bcbd2f Upgrade Aether 1.0 when available - Key: MNG-5562 URL: https://jira.codehaus.org/browse/MNG-5562 Project: Maven Issue Type: Task Components: Artifacts and Repositories Affects Versions: 3.0.4, 3.0.5, 3.1.0-alpha-1, 3.1.0, 3.1.1 Reporter: Robert Scholte Assignee: Igor Fedorenko Priority: Minor Fix For: 3.2.4 Attachments: aether-upgrade.patch Aether-0.9.0-M4 fixes a couple of issues, for instance MDEP-405/MNG-5366 Upgrading is a bit tricky due to changed artifacts, see http://wiki.eclipse.org/Aether/New_and_Noteworthy#Transporters The attached patch contains the upgrade. Jason advises to wait for Aether-1.0, which should be coming Real Soon (tm) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5366) [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4
[ https://jira.codehaus.org/browse/MNG-5366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=351953#comment-351953 ] Igor Fedorenko commented on MNG-5366: - This maybe fixed by the new aether I just integrated in maven, but hard to tell for sure without example project or unit test to demonstrate the original problem. [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4 -- Key: MNG-5366 URL: https://jira.codehaus.org/browse/MNG-5366 Project: Maven Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0.4, 3.0.5, 3.1.0, 3.1.1, 3.2.1, 3.2.2 Reporter: Paul Gier Fix For: Issues to be reviewed for 4.x Using Maven 3.0.4, artifacts can only be resolved a single time during the build lifecycle using the Maven 2.x dependency resolution API. Using resolver.resolveAlways() should force re-resolution of the artifact, however if the artifact was already resolved once during the build, then it will not be re-resolved even when calling resolveAlways(). This works as expected in Maven 3.0.0-3.0.3, and the artifact is re-resolved. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5366) [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4
[ https://jira.codehaus.org/browse/MNG-5366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=351954#comment-351954 ] Robert Scholte commented on MNG-5366: - {{maven-dependency-plugin\src\it\projects\purge-local-repository-reresolve}} should verify this. [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4 -- Key: MNG-5366 URL: https://jira.codehaus.org/browse/MNG-5366 Project: Maven Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0.4, 3.0.5, 3.1.0, 3.1.1, 3.2.1, 3.2.2 Reporter: Paul Gier Fix For: Issues to be reviewed for 4.x Using Maven 3.0.4, artifacts can only be resolved a single time during the build lifecycle using the Maven 2.x dependency resolution API. Using resolver.resolveAlways() should force re-resolution of the artifact, however if the artifact was already resolved once during the build, then it will not be re-resolved even when calling resolveAlways(). This works as expected in Maven 3.0.0-3.0.3, and the artifact is re-resolved. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5684) deployment happens twice
[ https://jira.codehaus.org/browse/MNG-5684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-5684: Component/s: Plugins and Lifecycle deployment happens twice Key: MNG-5684 URL: https://jira.codehaus.org/browse/MNG-5684 Project: Maven Issue Type: Bug Components: Deployment, Plugins and Lifecycle Affects Versions: 3.2.3 Environment: Windows 7, Java 8. Happened on Linux distributions (also Java 8) as well. Reporter: Tobias Stoeckmann Attachments: 3.2.2-clean-install-deploy.log, 3.2.3-clean-install-deploy.log, my-app.zip Since version 3.2.3, clean install deploy will deploy javadoc and source jars twice, which fails on our deployment policy. Release versions can be deployed only once. clean deploy fixes the issue, clean install deploy triggers it. clean install alone is okay, too. It installs javadoc and source jars only once. Please see attached a minimal example project, it's created through archetype. I've added javadoc and install plugin, as well as distributionManagement to deploy into test directory of user's home. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5684) deployment happens twice
[ https://jira.codehaus.org/browse/MNG-5684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-5684: Labels: (was: 3.2.3 deploy deployment regression twice) deployment happens twice Key: MNG-5684 URL: https://jira.codehaus.org/browse/MNG-5684 Project: Maven Issue Type: Bug Components: Deployment, Plugins and Lifecycle Affects Versions: 3.2.3 Environment: Windows 7, Java 8. Happened on Linux distributions (also Java 8) as well. Reporter: Tobias Stoeckmann Attachments: 3.2.2-clean-install-deploy.log, 3.2.3-clean-install-deploy.log, my-app.zip Since version 3.2.3, clean install deploy will deploy javadoc and source jars twice, which fails on our deployment policy. Release versions can be deployed only once. clean deploy fixes the issue, clean install deploy triggers it. clean install alone is okay, too. It installs javadoc and source jars only once. Please see attached a minimal example project, it's created through archetype. I've added javadoc and install plugin, as well as distributionManagement to deploy into test directory of user's home. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5684) deployment happens twice
[ https://jira.codehaus.org/browse/MNG-5684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-5684: Component/s: Deployment deployment happens twice Key: MNG-5684 URL: https://jira.codehaus.org/browse/MNG-5684 Project: Maven Issue Type: Bug Components: Deployment, Plugins and Lifecycle Affects Versions: 3.2.3 Environment: Windows 7, Java 8. Happened on Linux distributions (also Java 8) as well. Reporter: Tobias Stoeckmann Attachments: 3.2.2-clean-install-deploy.log, 3.2.3-clean-install-deploy.log, my-app.zip Since version 3.2.3, clean install deploy will deploy javadoc and source jars twice, which fails on our deployment policy. Release versions can be deployed only once. clean deploy fixes the issue, clean install deploy triggers it. clean install alone is okay, too. It installs javadoc and source jars only once. Please see attached a minimal example project, it's created through archetype. I've added javadoc and install plugin, as well as distributionManagement to deploy into test directory of user's home. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-404) Goal resource-bundle generates faulty jar file
Holger Mense created MJAVADOC-404: - Summary: Goal resource-bundle generates faulty jar file Key: MJAVADOC-404 URL: https://jira.codehaus.org/browse/MJAVADOC-404 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.9.1 Environment: Maven 3.0.4, Windows 7 Reporter: Holger Mense Attachments: resource-bundle-showcase.zip Hi, I am generating a javadoc-resources jar using resource-bundle goal. My project has additional JavaDoc resources in directory src/main/javadoc which contains several subdirectories. So the file structure is as follows: src/main/javadoc/foo src/main/javadoc/bar The generated javadoc-resources jar then contains the following structure: META-INF/ resources/ resourcesfoo/ resourcesbar/ There seems to be a directory separator missing when generating the destination directory structure. See attached showcase as example. Generated result is already included in target/ directory. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-298) Continuous Integration support for Travis CI
Philippe Marschall created MPIR-298: --- Summary: Continuous Integration support for Travis CI Key: MPIR-298 URL: https://jira.codehaus.org/browse/MPIR-298 Project: Maven Project Info Reports Plugin Issue Type: Improvement Components: cim Affects Versions: 2.7 Reporter: Philippe Marschall Attachments: travis-ci.patch Recognizes [Travis CI|https://travis-ci.org/] as a CIM system. Travis CI is popular with GitHub projects. The patch is modeled after MPIR-224 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-89) Use a more uncommon port for Jetty in the DefaultIndexUpdaterEmbeddingIT to avoid Address already in use
[ https://jira.codehaus.org/browse/MINDEXER-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov reassigned MINDEXER-89: -- Assignee: Martin Todorov Use a more uncommon port for Jetty in the DefaultIndexUpdaterEmbeddingIT to avoid Address already in use -- Key: MINDEXER-89 URL: https://jira.codehaus.org/browse/MINDEXER-89 Project: Maven Indexer Issue Type: Task Reporter: Martin Todorov Assignee: Martin Todorov Fix For: 6.0 The DefaultIndexUpdaterEmbeddingIT integration test will fail, if executing on a system which is already using port 8080. It's quite common for this port to already be open on a developer's machine (or server), if they're running Tomcat or Jenkins. {code} DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use {code} Perhaps the build-helper-maven-plugin could be used here to reserve a port. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-89) Use a more uncommon port for Jetty in the DefaultIndexUpdaterEmbeddingIT to avoid Address already in use
[ https://jira.codehaus.org/browse/MINDEXER-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=351975#comment-351975 ] Martin Todorov commented on MINDEXER-89: Created [pull/6|https://github.com/apache/maven-indexer/pull/6]. @cstamas / @hboutemy: Could you please review this change and merge it? Thanks! Use a more uncommon port for Jetty in the DefaultIndexUpdaterEmbeddingIT to avoid Address already in use -- Key: MINDEXER-89 URL: https://jira.codehaus.org/browse/MINDEXER-89 Project: Maven Indexer Issue Type: Task Reporter: Martin Todorov Assignee: Martin Todorov Fix For: 6.0 The DefaultIndexUpdaterEmbeddingIT integration test will fail, if executing on a system which is already using port 8080. It's quite common for this port to already be open on a developer's machine (or server), if they're running Tomcat or Jenkins. {code} DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use {code} Perhaps the build-helper-maven-plugin could be used here to reserve a port. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-92) Make the BasicUsageExampleTest download an index from the local machine, instead of Maven Central
Martin Todorov created MINDEXER-92: -- Summary: Make the BasicUsageExampleTest download an index from the local machine, instead of Maven Central Key: MINDEXER-92 URL: https://jira.codehaus.org/browse/MINDEXER-92 Project: Maven Indexer Issue Type: Test Reporter: Martin Todorov Currently, the BasicUsageExampleTest tries to connect to Maven Central in order to download an index to use as test data. This should be replaced with a call to localhost, where an embedded Jetty should be listening via the jetty-maven-plugin. The index files should be available for download from there, instead of having to wait for a hundred megs to arrive over the net. A simple index with some valid test data could easily be generated. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MACR-5) Usage page is wrong: Maven 3.0.4 does not include ACR plugin
[ https://jira.codehaus.org/browse/MACR-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise resolved MACR-5. Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed [r1621170|http://svn.apache.org/r1621170]. Usage page is wrong: Maven 3.0.4 does not include ACR plugin Key: MACR-5 URL: https://jira.codehaus.org/browse/MACR-5 Project: Maven ACR Plugin Issue Type: Bug Affects Versions: 1.0 Environment: http://maven.apache.org/plugins/maven-acr-plugin/usage.html Reporter: Markus KARG Assignee: Karl-Heinz Marbaise Priority: Minor Fix For: 1.1 The page http://maven.apache.org/plugins/maven-acr-plugin/usage.html says that when using Maven PRIOR 3.0.4, the ACR extension has to be explicitly enabled. This is wrong. I am using Maven 3.0.4 and STILL have to explicitly enable the extension, too. So obviously it is not true that this is only needed PRIOR to 3.0.4, but INLCUDING 3.0.4! This is confusing and should get changed ASAP. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1028) Unable to run single test (junit)
[ https://jira.codehaus.org/browse/SUREFIRE-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=351988#comment-351988 ] Tibor Digana commented on SUREFIRE-1028: Fixed in https://github.com/apache/maven-surefire/pull/46 Unable to run single test (junit) - Key: SUREFIRE-1028 URL: https://jira.codehaus.org/browse/SUREFIRE-1028 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.16 Reporter: Diwaker Gupta Priority: Critical Fix For: 2.18 This is a regression from 2.15. It also looks like Surefire keeps regressing on this feature (e.g. see SUREFIRE-827) -- are there no unit or integration tests to prevent such regressions? With Surefire 2.15 {noformat} $ mvn test -Dtest=MyTest#testFoo ... Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 {noformat} With Surefire 2.16 {noformat} $ mvn test -Dtest=MyTest#testFoo Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 {noformat} -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5676) mvn -U crashes with IBM JDK
[ https://jira.codehaus.org/browse/MNG-5676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5676: --- Assignee: Jason van Zyl mvn -U crashes with IBM JDK --- Key: MNG-5676 URL: https://jira.codehaus.org/browse/MNG-5676 Project: Maven Issue Type: Bug Affects Versions: 3.1.1, 3.2.2, 3.2.3 Environment: IBM JDK, OpenSuSE enterprise server 11 Reporter: Dan Tran Assignee: Jason van Zyl Fix For: 3.2.4 details discussion is at http://maven.40175.n5.nabble.com/Upgrade-to-3-1-1-causes-problems-td5776875.html work around is replace boot/plexus-classworlds-2.5.x.jar with plexus-classworlds-2.4.1.jar as discussed at the link -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5684) deployment happens twice
[ https://jira.codehaus.org/browse/MNG-5684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=351989#comment-351989 ] Jason van Zyl commented on MNG-5684: Maven will run the whole lifecycle again if you tell it to and I observe this with 3.2.1, 3.2.2, and 3.2.3. I agree that it should canonicalize and normalize but the behaviour has not changed. Why are you calling clean install deploy? You only need to call clean deploy if you want to deploy. deployment happens twice Key: MNG-5684 URL: https://jira.codehaus.org/browse/MNG-5684 Project: Maven Issue Type: Bug Components: Deployment, Plugins and Lifecycle Affects Versions: 3.2.3 Environment: Windows 7, Java 8. Happened on Linux distributions (also Java 8) as well. Reporter: Tobias Stoeckmann Attachments: 3.2.2-clean-install-deploy.log, 3.2.3-clean-install-deploy.log, my-app.zip Since version 3.2.3, clean install deploy will deploy javadoc and source jars twice, which fails on our deployment policy. Release versions can be deployed only once. clean deploy fixes the issue, clean install deploy triggers it. clean install alone is okay, too. It installs javadoc and source jars only once. Please see attached a minimal example project, it's created through archetype. I've added javadoc and install plugin, as well as distributionManagement to deploy into test directory of user's home. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5684) deployment happens twice
[ https://jira.codehaus.org/browse/MNG-5684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5684. -- Resolution: Cannot Reproduce deployment happens twice Key: MNG-5684 URL: https://jira.codehaus.org/browse/MNG-5684 Project: Maven Issue Type: Bug Components: Deployment, Plugins and Lifecycle Affects Versions: 3.2.3 Environment: Windows 7, Java 8. Happened on Linux distributions (also Java 8) as well. Reporter: Tobias Stoeckmann Attachments: 3.2.2-clean-install-deploy.log, 3.2.3-clean-install-deploy.log, my-app.zip Since version 3.2.3, clean install deploy will deploy javadoc and source jars twice, which fails on our deployment policy. Release versions can be deployed only once. clean deploy fixes the issue, clean install deploy triggers it. clean install alone is okay, too. It installs javadoc and source jars only once. Please see attached a minimal example project, it's created through archetype. I've added javadoc and install plugin, as well as distributionManagement to deploy into test directory of user's home. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5676) mvn -U crashes with IBM JDK
[ https://jira.codehaus.org/browse/MNG-5676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-5676: --- Fix Version/s: 3.2.4 Affects Version/s: 3.2.3 mvn -U crashes with IBM JDK --- Key: MNG-5676 URL: https://jira.codehaus.org/browse/MNG-5676 Project: Maven Issue Type: Bug Affects Versions: 3.1.1, 3.2.2, 3.2.3 Environment: IBM JDK, OpenSuSE enterprise server 11 Reporter: Dan Tran Fix For: 3.2.4 details discussion is at http://maven.40175.n5.nabble.com/Upgrade-to-3-1-1-causes-problems-td5776875.html work around is replace boot/plexus-classworlds-2.5.x.jar with plexus-classworlds-2.4.1.jar as discussed at the link -- This message was sent by Atlassian JIRA (v6.1.6#6162)