[jira] (MNG-5315) Artifact resolution sporadically fails in parallel builds
[
https://jira.codehaus.org/browse/MNG-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=329729#comment-329729
]
Sandy McPherson commented on MNG-5315:
--
My first fix was with a 3.1-SNAPSHOT from the beginning of June. I then went
back and patched 3.0.5 as we didn't want to use a snapshot. The 3.1-SNAPSHOT I
checked out a version from June 2 21:32:45 (last committer Arnaud Heritier).
This was definitely still broken.
Artifact resolution sporadically fails in parallel builds
-
Key: MNG-5315
URL: https://jira.codehaus.org/browse/MNG-5315
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.0.4
Reporter: Ivan S. Dubrov
Assignee: Jason van Zyl
Priority: Minor
Artifact resolution can fail during the parallel build if it was downloaded
during the same session.
Scenario:
1) Delete the whole Maven local repository.
2) Run build mvn compile -T1.5C
3) Build fails (see log extracts below)
4) If I run build again, it succeeds.
It seems like the problem is due to two thread trying to resolve same
artifact concurrently. This problem never happens once I have all
dependencies cached in the local repository.
Extracts from the log output:
{noformat}Downloading:
http://nexus/content/repositories/thirdparty/com/googlecode/guava-osgi/guava-osgi/11.0.0/guava-osgi-11.0.0.jar
12444/13937 KB ...
...
[DEBUG] Skipped remote update check for commons-cli:commons-cli:jar:1.2,
already updated during this session.
[DEBUG] Skipped remote update check for
com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, already updated during this
session.
[DEBUG] Skipped remote update check for org.slf4j:slf4j-api:jar:1.6.4,
already updated during this session.
[DEBUG] Skipped remote update check for org.slf4j:slf4j-jdk14:jar:1.6.4,
already updated during this session.
...
[ERROR] Failed to execute goal on project util: Could not resolve
dependencies for project com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The
following artifacts could not be resolved: commons-cli:commons-cli:jar:1.2,
com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
find commons-cli:commons-cli:jar:1.2 in
http://nexus/content/repositories/thirdparty was cached in the local
repository, resolution will not be reattempted until the update interval of
gw.thirdparty has elapsed or updates are forced - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal on project util: Could not resolve dependencies for project
com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The following artifacts could not
be resolved: commons-cli:commons-cli:jar:1.2,
com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
find commons-cli:commons-cli:jar:1.2 in
http://nexus/content/repositories/thirdparty was cached in the local
repository, resolution will not be reattempted until the update interval of
gw.thirdparty has elapsed or updates are forced
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
at
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
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.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
[jira] (MRRESOURCES-61) processed resources are added to main and test resources
[ https://jira.codehaus.org/browse/MRRESOURCES-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg reassigned MRRESOURCES-61: -- Assignee: Dennis Lundberg processed resources are added to main and test resources Key: MRRESOURCES-61 URL: https://jira.codehaus.org/browse/MRRESOURCES-61 Project: Maven 2.x Remote Resources Plugin Issue Type: Bug Affects Versions: 1.3 Environment: Windows 7 Reporter: David Tombs Assignee: Dennis Lundberg Priority: Minor Attachments: mrreserouces-61-project.zip When attached is set to true, Maven Remote Resources Plugin adds processed resources to both the main and test resources directories. I see no reason to add the resources to the test directory unless explicitly specified because the test classpath by default includes the main resources as well. The disadvantage to including the resources in both the main and test directories is that you end up with duplicate files on the class path which, for example, can make logback complain about multiple logback.xml files. The code in question is on lines 533-534 of ProcessRemoteResourcesMojo.java. If you need an example project I can make one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-374) dependency:tree -Dverbose isn't verbose anymore
[ https://jira.codehaus.org/browse/MDEP-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=329745#comment-329745 ] Ittai Zeidman commented on MDEP-374: Any chance of revisiting this to an actual maven3 resolution? Now that maven 3.1 is out maybe that makes it easier for you (don't know just asking) dependency:tree -Dverbose isn't verbose anymore --- Key: MDEP-374 URL: https://jira.codehaus.org/browse/MDEP-374 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: tree Affects Versions: 2.5, 2.5.1 Environment: maven 3.0.4 windows7 and linux Reporter: Arne Brix Assignee: Herve Boutemy Priority: Minor Fix For: 2.8 Older versions of the plugin (for example 2.4) show information about duplicates when invoked with -Dverbose. The current versions show no reaction to -Dverbose at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-162) maven-enforcer-plugin 1.3.1 no longer fails when duplicate classes are found
David Boden created MENFORCER-162: - Summary: maven-enforcer-plugin 1.3.1 no longer fails when duplicate classes are found Key: MENFORCER-162 URL: https://jira.codehaus.org/browse/MENFORCER-162 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Components: Plugin Reporter: David Boden Priority: Critical I'll provide more details if this proves difficult to recreate. For now, I just wanted to log my observation that 1.3.1 does not find duplicate classes on the classpath whereas 1.3 does. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5498) LinkageError with Maven Plugin using Aether
[ https://jira.codehaus.org/browse/MNG-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Gastaldi updated MNG-5498: - Summary: LinkageError with Maven Plugin using Aether (was: VerifyError with Maven Plugin using Aether) LinkageError with Maven Plugin using Aether --- Key: MNG-5498 URL: https://jira.codehaus.org/browse/MNG-5498 Project: Maven 2 3 Issue Type: Bug Components: Class Loading Affects Versions: 3.0.5 Environment: Maven 3.0.5 Reporter: George Gastaldi Full description here: http://stackoverflow.com/questions/17837651/verifyerror-with-maven-plugin-using-aether -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5498) LinkageError with Maven Plugin using Aether 1.13.1
[ https://jira.codehaus.org/browse/MNG-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Gastaldi updated MNG-5498: - Summary: LinkageError with Maven Plugin using Aether 1.13.1 (was: LinkageError with Maven Plugin using Aether) LinkageError with Maven Plugin using Aether 1.13.1 -- Key: MNG-5498 URL: https://jira.codehaus.org/browse/MNG-5498 Project: Maven 2 3 Issue Type: Bug Components: Class Loading Affects Versions: 3.0.5 Environment: Maven 3.0.5 Reporter: George Gastaldi Full description here: http://stackoverflow.com/questions/17837651/verifyerror-with-maven-plugin-using-aether -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5498) LinkageError with Maven Plugin using Aether 1.13.1
[ https://jira.codehaus.org/browse/MNG-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=329757#comment-329757 ] Jason van Zyl commented on MNG-5498: This is expected for plugins that use Sonatype Aether directly. I believe the JBoss Forge authors are on it. LinkageError with Maven Plugin using Aether 1.13.1 -- Key: MNG-5498 URL: https://jira.codehaus.org/browse/MNG-5498 Project: Maven 2 3 Issue Type: Bug Components: Class Loading Affects Versions: 3.0.5 Environment: Maven 3.0.5 Reporter: George Gastaldi Full description here: http://stackoverflow.com/questions/17837651/verifyerror-with-maven-plugin-using-aether -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5498) LinkageError with Maven Plugin using Aether 1.13.1
[ https://jira.codehaus.org/browse/MNG-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5498. -- Resolution: Won't Fix LinkageError with Maven Plugin using Aether 1.13.1 -- Key: MNG-5498 URL: https://jira.codehaus.org/browse/MNG-5498 Project: Maven 2 3 Issue Type: Bug Components: Class Loading Affects Versions: 3.0.5 Environment: Maven 3.0.5 Reporter: George Gastaldi Full description here: http://stackoverflow.com/questions/17837651/verifyerror-with-maven-plugin-using-aether -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-695) java.lang.NullPointerException in org.apache.maven.plugins.site.SiteStageDeployMojo.getTopMostParentWithSameStagingSiteURL
[
https://jira.codehaus.org/browse/MSITE-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated MSITE-695:
---
Priority: Blocker (was: Major)
I am marking this as a blocker because we cannot use Maven 3.1.0 with Log4J 2
until this is fixed.
java.lang.NullPointerException in
org.apache.maven.plugins.site.SiteStageDeployMojo.getTopMostParentWithSameStagingSiteURL
--
Key: MSITE-695
URL: https://jira.codehaus.org/browse/MSITE-695
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:stage(-deploy)
Affects Versions: 3.2, 3.3
Environment: Apache Maven 3.0.5
(r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 08:51:28-0500)
Maven home: C:\Java\apache-maven-3.0.5\bin\..
Java version: 1.7.0_25, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_25\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
and
C:\vcs\svn\apache\log4j2\trunkC:\Java\apache-maven-3.1.0\bin\mvn.bat -version
Apache Maven 3.1.0 (893ca28a1da9d5f51ac03827af98bb730128f9f2; 2013-06-27
22:15:32-0400)
Maven home: C:\Java\apache-maven-3.1.0\bin\..
Java version: 1.7.0_25, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_25\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
Reporter: Gary Gregory
Priority: Blocker
Checkout log4j 2 from:
https://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk
The HEAD of trunk is currently revision 1504131.
Run:
mvn clean site
Get:
{noformat}[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 3.724s
[INFO] Finished at: Wed Jul 17 12:43:47 EDT 2013
[INFO] Final Memory: 22M/213M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.3:stage-deploy (default-cli) on
project log4j: Execution default-cli of goal
org.apache.maven.plugins:maven-site-plugin:3.3:stage-deploy failed.
NullPointerException - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-site-plugin:3.3:stage-deploy
(default-cli) on project log4j: Execution default-cli of goal
org.apache.maven.plugins:maven-site-plugin:3.3:stage-deploy failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
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:318)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
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:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:414)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-cli of goal
org.apache.maven.plugins:maven-site-plugin:3.3:stage-deploy failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused
[jira] (MRRESOURCES-61) processed resources are added to main and test resources
[ https://jira.codehaus.org/browse/MRRESOURCES-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MRRESOURCES-61. -- Resolution: Fixed Fix Version/s: 1.5 I added two new parameters attachToMain and attachToTest that will replace the old attach parameter. The old parameter is still available and working as before. Fixed in [r1507978|http://svn.apache.org/viewvc?view=revisionrevision=1507978]. processed resources are added to main and test resources Key: MRRESOURCES-61 URL: https://jira.codehaus.org/browse/MRRESOURCES-61 Project: Maven 2.x Remote Resources Plugin Issue Type: Bug Affects Versions: 1.3 Environment: Windows 7 Reporter: David Tombs Assignee: Dennis Lundberg Priority: Minor Fix For: 1.5 Attachments: mrreserouces-61-project.zip When attached is set to true, Maven Remote Resources Plugin adds processed resources to both the main and test resources directories. I see no reason to add the resources to the test directory unless explicitly specified because the test classpath by default includes the main resources as well. The disadvantage to including the resources in both the main and test directories is that you end up with duplicate files on the class path which, for example, can make logback complain about multiple logback.xml files. The code in question is on lines 533-534 of ProcessRemoteResourcesMojo.java. If you need an example project I can make one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MJAVADOC-373) Make generated Javadoc html files have consistent new line endings
Marshall Schor created MJAVADOC-373: --- Summary: Make generated Javadoc html files have consistent new line endings Key: MJAVADOC-373 URL: https://jira.codehaus.org/browse/MJAVADOC-373 Project: Maven 2.x Javadoc Plugin Issue Type: New Feature Affects Versions: 2.9.1 Environment: Windows Reporter: Marshall Schor On Windows, running the plugin results in Javadoc html files being built which have both cr lf and lf style line endings. Now that Apache requires uploads for releases via SVN, and because the default for SVN for new files (if using the standard conventional Apache settings from http://apache.org/dev/svn-eol-style.txt ) adds the svn property eol-style:native, SVN throws an error and won't upload the files because it finds mixed end-of-line characters in the file. It would nice if there was a new option, which (if set) would cause something like Ant's fixcrlf to be run on the generated .html files after the Javadoc generation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-162) maven-enforcer-plugin 1.3.1 no longer fails when duplicate classes are found
[ https://jira.codehaus.org/browse/MENFORCER-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=329776#comment-329776 ] Robert Scholte commented on MENFORCER-162: -- As weird as it may sound, but it is actually a extra-enforcer-rule issue. It expects that all dependencies are already resolved, which is an invalid assumption. There are more extra-enforcer-rules which have this kind of problems, I've already started to fix it there. I'll leave this issue open until the extra-enforcer-rules are fixed, because I'm pretty sure more users will blame the maven-enforcer-plugin. maven-enforcer-plugin 1.3.1 no longer fails when duplicate classes are found Key: MENFORCER-162 URL: https://jira.codehaus.org/browse/MENFORCER-162 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Components: Plugin Reporter: David Boden Priority: Critical I'll provide more details if this proves difficult to recreate. For now, I just wanted to log my observation that 1.3.1 does not find duplicate classes on the classpath whereas 1.3 does. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
