[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)
