[jira] (MEAR-158) Elements library-directory and env-entry out of sequence in application.xml for JEE 6
[ https://jira.codehaus.org/browse/MEAR-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325871#comment-325871 ] David Forsman commented on MEAR-158: Please release minor version for this. Simple bug to correct. Glassfish is rely picky and validates the application.xml at deploy. (I need this to be able to build ear for both Glassfish and JBoss. Glassfish is strict on class loading.) > Elements library-directory and env-entry out of sequence in application.xml > for JEE 6 > - > > Key: MEAR-158 > URL: https://jira.codehaus.org/browse/MEAR-158 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Marty Phelan > Fix For: 2.8.1 > > Attachments: application.xml, pom.xml, pom.xml, pom.xml > > > When the pom.xml for an JEE 6 EAR project contains plugin configuration > entries for both defaultLibBundleDir and env-entries, the resulting elements > in application.xml are out-of-sequence per specification. The generated order > is env-entry - library-directory. This should be reversed. > Attached are two files: the sample pom.xml and resulting application.xml. -- 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-412) add an option to copy dependencies with their parent poms + parent poms of current project
[
https://jira.codehaus.org/browse/MDEP-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325876#comment-325876
]
Gauthier JACQUES commented on MDEP-412:
---
Hi,
Why the hell didn't you add {{property="mdep.addParentPoms"}} in the parameter
annotation ?
I need to use this option with the invoker plugin and I'm stuck because I can't
pass it as a user property.
Is it possible to fix this ?
Thanks, regards,
Gauthier
> add an option to copy dependencies with their parent poms + parent poms of
> current project
> --
>
> Key: MDEP-412
> URL: https://jira.codehaus.org/browse/MDEP-412
> Project: Maven 2.x Dependency Plugin
> Issue Type: New Feature
> Components: copy-dependencies
>Affects Versions: 2.7
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 2.8
>
>
> this will copy every effective dependencies
--
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] (WAGON-381) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
https://jira.codehaus.org/browse/WAGON-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325883#comment-325883
]
Henri Gomez commented on WAGON-381:
---
Tested with latest Maven 3.1-SNAPSHOT, same problem :
{code}
Apache Maven 3.1-SNAPSHOT (ac64dd6bb6096e8dbd54e3520208e5737fb1c804; 2013-05-29
18:48:30-0700)
Maven home: /root/apache-maven-3.1-SNAPSHOT
Java version: 1.6.0_45, vendor: Sun Microsystems Inc.
Java home: /opt/mycorp/jvm/java-1.6.0-sun-x64/jre
Default locale: fr_FR, platform encoding: UTF-8
OS name: "linux", version: "3.4.33-2.24-default", arch: "amd64", family: "unix"
{code}
Artifact is 2.5Gb long
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: WAGON-381
> URL: https://jira.codehaus.org/browse/WAGON-381
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 2.2
>Reporter: Evgeny Goldin
>Assignee: Olivier Lamy
> Fix For: 2.3
>
> Attachments: 1.png, 2.png
>
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
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] (ARCHETYPE-422) Unable to find resource 'archetype-resources/*/pom.xml'
[ https://jira.codehaus.org/browse/ARCHETYPE-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325898#comment-325898 ] Julien Torrielli commented on ARCHETYPE-422: Same problem. > Unable to find resource 'archetype-resources/*/pom.xml' > --- > > Key: ARCHETYPE-422 > URL: https://jira.codehaus.org/browse/ARCHETYPE-422 > Project: Maven Archetype > Issue Type: Bug > Components: Generator > Environment: Windows 7, Apache Maven 3.0.4 (r1232337; 2012-01-17 > 00:44:56-0800) > Java version: 1.6.0_30, vendor: Sun Microsystems Inc. >Reporter: Aleksei Serov >Priority: Minor > Attachments: archetype.zip > > > I am running a mvn archetype:generate on multi-module project archetype I > have created using mvn archetype:create-from-project and mvn install. > Archetype attached. > I get: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-archetype-plugin:2.2:generate (default-cli) on > project standalone-pom: > org.apache.maven.archetype.exception.ArchetypeGenerationFailure: Error > merging velocity templates: Unable to find resource > 'archetype-resources/*/pom.xml' -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-archetype-plugin:2.2:generate > (default-cli) on project standalone-pom: > org.apache.maven.archetype.exception.ArchetypeGenerationFailure: Error > merging velocity templates: Unable to find resource > 'archetype-resources/*/pom.xml' -- 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] (SUREFIRE-999) Skip phase `validate` during site-generation for `report-only` resp. `failsafe-report-only`
[
https://jira.codehaus.org/browse/SUREFIRE-999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325902#comment-325902
]
Kristian Rosenvold commented on SUREFIRE-999:
-
I asked about this on github; but I could't see from the diff why you needed to
duplicate the code (which change did you need to make because you moved
superclass one level up ?)
> Skip phase `validate` during site-generation for `report-only` resp.
> `failsafe-report-only`
>
>
> Key: SUREFIRE-999
> URL: https://jira.codehaus.org/browse/SUREFIRE-999
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.14.1, 2.15
>Reporter: Mirko Friedenhagen
>
> * We have a lot of projects in our CI system (Jenkins) where we run {{mvn
> clean deploy site-deploy}}.
> * Because of this, we do not repeat test execution again during phase
> {{site}} by defining the {{reportSet}} to include {{report-only}}.
> * However, {{report-only}} does invoke the phase {{validate}} again which
> will execute some lengthy {{enforcer}} checks.
> * I created a clone of {{maven-surefire}} where I did redefine
> {{report-only}} to not fork the lifecyle and have a small integration-test
> project
> https://github.com/mfriedenhagen/pastebin/tree/surefire-reportonly-test which
> will show the issue:
> * Running {{mvn -e}} will produce the following output:
> {code}
> [INFO] --- maven-site-plugin:3.0:site (default-site) @
> surefire-reportonly-test ---
> [INFO] configuring report plugin org.apache.maven.plugins:maven-jxr-plugin:2.3
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-surefire-report-plugin:2.14.1
> [INFO]
> [INFO] >>> maven-surefire-report-plugin:2.14.1:report-only
> (report:report-only) @ surefire-reportonly-test >>>
> [INFO]
> [INFO] <<< maven-surefire-report-plugin:2.14.1:report-only
> (report:report-only) @ surefire-reportonly-test <<<
> [INFO]
> [INFO] >>> maven-surefire-report-plugin:2.14.1:failsafe-report-only
> (report:failsafe-report-only) @ surefire-reportonly-test >>>
> [INFO]
> [INFO] <<< maven-surefire-report-plugin:2.14.1:failsafe-report-only
> (report:failsafe-report-only) @ surefire-reportonly-test <<<
> [INFO] Relativizing decoration links with respect to project URL:
> https://github.com/mfriedenhagen/pastebin
> {code}
> * When running {{mvn -e -Dmaven-surefire-plugin.version=2.15-SNAPSHOT}} the
> following output will be produced:
> {code}
> [INFO] --- maven-site-plugin:3.0:site (default-site) @
> surefire-reportonly-test ---
> [INFO] configuring report plugin org.apache.maven.plugins:maven-jxr-plugin:2.3
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-surefire-report-plugin:2.15-SNAPSHOT
> [INFO] Relativizing decoration links with respect to project URL:
> https://github.com/mfriedenhagen/pastebin
> [INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0
> skin.
> [INFO] Skipped "Test Source Xref" report, file "xref-test/index.html" already
> exists for the English version.
> [INFO] Generating "Test Source Xref" report--- maven-jxr-plugin:2.3
> [INFO] Generating "Surefire Report" report---
> maven-surefire-report-plugin:2.15-SNAPSHOT
> [INFO] Generating "Failsafe Report" report---
> maven-surefire-report-plugin:2.15-SNAPSHOT
> [INFO]
>
> {code}
> I will include the pull request in a comment.
--
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] (SUREFIRE-999) Skip phase `validate` during site-generation for `report-only` resp. `failsafe-report-only`
[
https://jira.codehaus.org/browse/SUREFIRE-999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325904#comment-325904
]
Mirko Friedenhagen commented on SUREFIRE-999:
-
Kristian, I replied to this on github, but the comment is now gone because I
did a push --force, sorry. I now included a description in the commit:
https://github.com/mfriedenhagen/maven-surefire/commit/7a8ad1f0f5cc7d07d1fd811943cc58d96efa371e
{quote}
Let `SurefireReportOnlyMojo` be a child of
`AbstractSurefireReportMojo` to avoid execution of phase validate.
Because Surefire uses doclet annotations and there is no way to specify a phase
`@execute phase="none"`,
`SurefireReportOnlyMojo` would inherit the execution of phase `test` from
`SurefireReportMojo`.
Alternatives to `SurefireReportOnlyMojo` extending from
`AbstractSurefireReportMojo` and duplicating setters etc.:
* Introduce another abstract class between `AbstractSurefireReportMojo` and
`SurefireReportMojo` which
defines the setters etc. and let both `SurefireReportMojo` and
`SurefireReportOnlyMojo` extend this, only
defining different goal-names and only `SurefireReportMojo` define `@execute`.
* Switch to Java annotations instead of doclet annotations.
Both approaches would have had a much bigger risk of introducing
incompatibilities.
{quote}
> Skip phase `validate` during site-generation for `report-only` resp.
> `failsafe-report-only`
>
>
> Key: SUREFIRE-999
> URL: https://jira.codehaus.org/browse/SUREFIRE-999
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.14.1, 2.15
>Reporter: Mirko Friedenhagen
>
> * We have a lot of projects in our CI system (Jenkins) where we run {{mvn
> clean deploy site-deploy}}.
> * Because of this, we do not repeat test execution again during phase
> {{site}} by defining the {{reportSet}} to include {{report-only}}.
> * However, {{report-only}} does invoke the phase {{validate}} again which
> will execute some lengthy {{enforcer}} checks.
> * I created a clone of {{maven-surefire}} where I did redefine
> {{report-only}} to not fork the lifecyle and have a small integration-test
> project
> https://github.com/mfriedenhagen/pastebin/tree/surefire-reportonly-test which
> will show the issue:
> * Running {{mvn -e}} will produce the following output:
> {code}
> [INFO] --- maven-site-plugin:3.0:site (default-site) @
> surefire-reportonly-test ---
> [INFO] configuring report plugin org.apache.maven.plugins:maven-jxr-plugin:2.3
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-surefire-report-plugin:2.14.1
> [INFO]
> [INFO] >>> maven-surefire-report-plugin:2.14.1:report-only
> (report:report-only) @ surefire-reportonly-test >>>
> [INFO]
> [INFO] <<< maven-surefire-report-plugin:2.14.1:report-only
> (report:report-only) @ surefire-reportonly-test <<<
> [INFO]
> [INFO] >>> maven-surefire-report-plugin:2.14.1:failsafe-report-only
> (report:failsafe-report-only) @ surefire-reportonly-test >>>
> [INFO]
> [INFO] <<< maven-surefire-report-plugin:2.14.1:failsafe-report-only
> (report:failsafe-report-only) @ surefire-reportonly-test <<<
> [INFO] Relativizing decoration links with respect to project URL:
> https://github.com/mfriedenhagen/pastebin
> {code}
> * When running {{mvn -e -Dmaven-surefire-plugin.version=2.15-SNAPSHOT}} the
> following output will be produced:
> {code}
> [INFO] --- maven-site-plugin:3.0:site (default-site) @
> surefire-reportonly-test ---
> [INFO] configuring report plugin org.apache.maven.plugins:maven-jxr-plugin:2.3
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-surefire-report-plugin:2.15-SNAPSHOT
> [INFO] Relativizing decoration links with respect to project URL:
> https://github.com/mfriedenhagen/pastebin
> [INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0
> skin.
> [INFO] Skipped "Test Source Xref" report, file "xref-test/index.html" already
> exists for the English version.
> [INFO] Generating "Test Source Xref" report--- maven-jxr-plugin:2.3
> [INFO] Generating "Surefire Report" report---
> maven-surefire-report-plugin:2.15-SNAPSHOT
> [INFO] Generating "Failsafe Report" report---
> maven-surefire-report-plugin:2.15-SNAPSHOT
> [INFO]
>
> {code}
> I will include the pull request in a comment.
--
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] (SUREFIRE-999) Skip phase `validate` during site-generation for `report-only` resp. `failsafe-report-only`
[
https://jira.codehaus.org/browse/SUREFIRE-999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325906#comment-325906
]
Kristian Rosenvold commented on SUREFIRE-999:
-
I just hate seeing that kind of duplication :) Can you try it with java
annotations ?
> Skip phase `validate` during site-generation for `report-only` resp.
> `failsafe-report-only`
>
>
> Key: SUREFIRE-999
> URL: https://jira.codehaus.org/browse/SUREFIRE-999
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.14.1, 2.15
>Reporter: Mirko Friedenhagen
>
> * We have a lot of projects in our CI system (Jenkins) where we run {{mvn
> clean deploy site-deploy}}.
> * Because of this, we do not repeat test execution again during phase
> {{site}} by defining the {{reportSet}} to include {{report-only}}.
> * However, {{report-only}} does invoke the phase {{validate}} again which
> will execute some lengthy {{enforcer}} checks.
> * I created a clone of {{maven-surefire}} where I did redefine
> {{report-only}} to not fork the lifecyle and have a small integration-test
> project
> https://github.com/mfriedenhagen/pastebin/tree/surefire-reportonly-test which
> will show the issue:
> * Running {{mvn -e}} will produce the following output:
> {code}
> [INFO] --- maven-site-plugin:3.0:site (default-site) @
> surefire-reportonly-test ---
> [INFO] configuring report plugin org.apache.maven.plugins:maven-jxr-plugin:2.3
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-surefire-report-plugin:2.14.1
> [INFO]
> [INFO] >>> maven-surefire-report-plugin:2.14.1:report-only
> (report:report-only) @ surefire-reportonly-test >>>
> [INFO]
> [INFO] <<< maven-surefire-report-plugin:2.14.1:report-only
> (report:report-only) @ surefire-reportonly-test <<<
> [INFO]
> [INFO] >>> maven-surefire-report-plugin:2.14.1:failsafe-report-only
> (report:failsafe-report-only) @ surefire-reportonly-test >>>
> [INFO]
> [INFO] <<< maven-surefire-report-plugin:2.14.1:failsafe-report-only
> (report:failsafe-report-only) @ surefire-reportonly-test <<<
> [INFO] Relativizing decoration links with respect to project URL:
> https://github.com/mfriedenhagen/pastebin
> {code}
> * When running {{mvn -e -Dmaven-surefire-plugin.version=2.15-SNAPSHOT}} the
> following output will be produced:
> {code}
> [INFO] --- maven-site-plugin:3.0:site (default-site) @
> surefire-reportonly-test ---
> [INFO] configuring report plugin org.apache.maven.plugins:maven-jxr-plugin:2.3
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-surefire-report-plugin:2.15-SNAPSHOT
> [INFO] Relativizing decoration links with respect to project URL:
> https://github.com/mfriedenhagen/pastebin
> [INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0
> skin.
> [INFO] Skipped "Test Source Xref" report, file "xref-test/index.html" already
> exists for the English version.
> [INFO] Generating "Test Source Xref" report--- maven-jxr-plugin:2.3
> [INFO] Generating "Surefire Report" report---
> maven-surefire-report-plugin:2.15-SNAPSHOT
> [INFO] Generating "Failsafe Report" report---
> maven-surefire-report-plugin:2.15-SNAPSHOT
> [INFO]
>
> {code}
> I will include the pull request in a comment.
--
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-5315) Artifact resolution sporadically fails in parallel builds
[
https://jira.codehaus.org/browse/MNG-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325915#comment-325915
]
Sandy McPherson commented on MNG-5315:
--
We're also seeing this using Teamcity and Nexus. Which repository are you guys
using? Could the root problem be Nexus related? Would appear that maven does
not find the dependency in Nexus. We have a couple of Nexus repositories which
are being searched.
> 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
>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 j
[jira] (MSHADE-97) Add the ability to specify "entry points" for minimizeJar
[
https://jira.codehaus.org/browse/MSHADE-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Katsubo updated MSHADE-97:
-
Attachment: entrypoints-2.1.patch
Another version, this time with mask support:
{code}
com.sun.media.imageioimpl.plugins.*ImageReader*
{code}
> Add the ability to specify "entry points" for minimizeJar
> --
>
> Key: MSHADE-97
> URL: https://jira.codehaus.org/browse/MSHADE-97
> Project: Maven 2.x Shade Plugin
> Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Jared Bunting
> Attachments: entrypoints-2.1.patch, entrypoints-2.1.patch,
> entrypoints.patch, entrypoints.patch
>
>
> Currently, the "minimizeJar" option assumes that you want to include all
> classes in the current project and those that they depend on. Sometimes,
> classes are accessed via reflection, or some other means, and therefore don't
> get included. The ability to specify additional entry points (as classes) to
> this dependency tree would be useful.
> I have added this as a patch that I am attaching.
--
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-5315) Artifact resolution sporadically fails in parallel builds
[
https://jira.codehaus.org/browse/MNG-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325932#comment-325932
]
Ivan S. Dubrov commented on MNG-5315:
-
No, it's not repository related. The issue never happens in a single-threaded
build. It looks like it happens due to the race-condition between two threads
trying to download the same artifact at the same time. Also, even though build
is failed the dependency is actually downloaded into the local repository (so
you can see it there after the build fails).
Something like (just speculating):
1) first thread looks into the local repository, nothing there, goes to the
remote repository
2) first thread downloads remote dependency, but does not update
_maven.repositories yet.
3) second thread looks into the local repository, sees the dependency, but
_maven.repositories does not contain remote repository id!
4) second thread fails with "Could not resolve dependencies", since it thinks
dependency is not available from the remote repository.
5) first thread updates _maven.repositories. Next time build is invoked,
dependency is used from the local repository.
> 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
>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)
>
[jira] (MNGSITE-178) [Site] The reference to Site Descriptor xsd/decoration-1.4.0.xsd does not work
Tjeerd Verhagen created MNGSITE-178: --- Summary: [Site] The reference to Site Descriptor xsd/decoration-1.4.0.xsd does not work Key: MNGSITE-178 URL: https://jira.codehaus.org/browse/MNGSITE-178 Project: Maven Project Web Site Issue Type: Bug Reporter: Tjeerd Verhagen Priority: Minor On the page: Decoration http://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html There is a reference (multiple times) to the decoration-1.4.0.xsd, but this XSD is not found at that location. http://maven.apache.org/xsd/decoration-1.4.0.xsd -- 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] (MNGSITE-179) [Site] Different versions of the Site Descriptor XSD are referenced (1.3.0 and 1.4.0)
Tjeerd Verhagen created MNGSITE-179: --- Summary: [Site] Different versions of the Site Descriptor XSD are referenced (1.3.0 and 1.4.0) Key: MNGSITE-179 URL: https://jira.codehaus.org/browse/MNGSITE-179 Project: Maven Project Web Site Issue Type: Bug Reporter: Tjeerd Verhagen Priority: Minor On the page: Decoration http://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html There is a reference (multiple times) to version 1.4.0 http://maven.apache.org/xsd/decoration-1.4.0.xsd On the page: Configuring the Site Descriptor http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html There is a reference to version 1.3.0 http://maven.apache.org/xsd/decoration-1.3.0.xsd Issue: better not to use 2 different versions -- 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] (SUREFIRE-999) Skip phase `validate` during site-generation for `report-only` resp. `failsafe-report-only`
[
https://jira.codehaus.org/browse/SUREFIRE-999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325947#comment-325947
]
Mirko Friedenhagen commented on SUREFIRE-999:
-
[~krosenvold]:
* this means, surefire can not be used with JDK1.4 anymore.
* this implies newer versions of {{maven-plugin}} etc.
> Skip phase `validate` during site-generation for `report-only` resp.
> `failsafe-report-only`
>
>
> Key: SUREFIRE-999
> URL: https://jira.codehaus.org/browse/SUREFIRE-999
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.14.1, 2.15
>Reporter: Mirko Friedenhagen
>
> * We have a lot of projects in our CI system (Jenkins) where we run {{mvn
> clean deploy site-deploy}}.
> * Because of this, we do not repeat test execution again during phase
> {{site}} by defining the {{reportSet}} to include {{report-only}}.
> * However, {{report-only}} does invoke the phase {{validate}} again which
> will execute some lengthy {{enforcer}} checks.
> * I created a clone of {{maven-surefire}} where I did redefine
> {{report-only}} to not fork the lifecyle and have a small integration-test
> project
> https://github.com/mfriedenhagen/pastebin/tree/surefire-reportonly-test which
> will show the issue:
> * Running {{mvn -e}} will produce the following output:
> {code}
> [INFO] --- maven-site-plugin:3.0:site (default-site) @
> surefire-reportonly-test ---
> [INFO] configuring report plugin org.apache.maven.plugins:maven-jxr-plugin:2.3
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-surefire-report-plugin:2.14.1
> [INFO]
> [INFO] >>> maven-surefire-report-plugin:2.14.1:report-only
> (report:report-only) @ surefire-reportonly-test >>>
> [INFO]
> [INFO] <<< maven-surefire-report-plugin:2.14.1:report-only
> (report:report-only) @ surefire-reportonly-test <<<
> [INFO]
> [INFO] >>> maven-surefire-report-plugin:2.14.1:failsafe-report-only
> (report:failsafe-report-only) @ surefire-reportonly-test >>>
> [INFO]
> [INFO] <<< maven-surefire-report-plugin:2.14.1:failsafe-report-only
> (report:failsafe-report-only) @ surefire-reportonly-test <<<
> [INFO] Relativizing decoration links with respect to project URL:
> https://github.com/mfriedenhagen/pastebin
> {code}
> * When running {{mvn -e -Dmaven-surefire-plugin.version=2.15-SNAPSHOT}} the
> following output will be produced:
> {code}
> [INFO] --- maven-site-plugin:3.0:site (default-site) @
> surefire-reportonly-test ---
> [INFO] configuring report plugin org.apache.maven.plugins:maven-jxr-plugin:2.3
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-surefire-report-plugin:2.15-SNAPSHOT
> [INFO] Relativizing decoration links with respect to project URL:
> https://github.com/mfriedenhagen/pastebin
> [INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0
> skin.
> [INFO] Skipped "Test Source Xref" report, file "xref-test/index.html" already
> exists for the English version.
> [INFO] Generating "Test Source Xref" report--- maven-jxr-plugin:2.3
> [INFO] Generating "Surefire Report" report---
> maven-surefire-report-plugin:2.15-SNAPSHOT
> [INFO] Generating "Failsafe Report" report---
> maven-surefire-report-plugin:2.15-SNAPSHOT
> [INFO]
>
> {code}
> I will include the pull request in a comment.
--
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] (SUREFIRE-999) Skip phase `validate` during site-generation for `report-only` resp. `failsafe-report-only`
[
https://jira.codehaus.org/browse/SUREFIRE-999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325947#comment-325947
]
Mirko Friedenhagen edited comment on SUREFIRE-999 at 5/30/13 1:42 PM:
--
[~krosenvold]:
* this means, surefire can not be used with JDK1.4 anymore.
* this implies newer versions of {{maven-plugin}} etc.
I will give it a try.
was (Author: mfriedenhagen):
[~krosenvold]:
* this means, surefire can not be used with JDK1.4 anymore.
* this implies newer versions of {{maven-plugin}} etc.
> Skip phase `validate` during site-generation for `report-only` resp.
> `failsafe-report-only`
>
>
> Key: SUREFIRE-999
> URL: https://jira.codehaus.org/browse/SUREFIRE-999
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.14.1, 2.15
>Reporter: Mirko Friedenhagen
>
> * We have a lot of projects in our CI system (Jenkins) where we run {{mvn
> clean deploy site-deploy}}.
> * Because of this, we do not repeat test execution again during phase
> {{site}} by defining the {{reportSet}} to include {{report-only}}.
> * However, {{report-only}} does invoke the phase {{validate}} again which
> will execute some lengthy {{enforcer}} checks.
> * I created a clone of {{maven-surefire}} where I did redefine
> {{report-only}} to not fork the lifecyle and have a small integration-test
> project
> https://github.com/mfriedenhagen/pastebin/tree/surefire-reportonly-test which
> will show the issue:
> * Running {{mvn -e}} will produce the following output:
> {code}
> [INFO] --- maven-site-plugin:3.0:site (default-site) @
> surefire-reportonly-test ---
> [INFO] configuring report plugin org.apache.maven.plugins:maven-jxr-plugin:2.3
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-surefire-report-plugin:2.14.1
> [INFO]
> [INFO] >>> maven-surefire-report-plugin:2.14.1:report-only
> (report:report-only) @ surefire-reportonly-test >>>
> [INFO]
> [INFO] <<< maven-surefire-report-plugin:2.14.1:report-only
> (report:report-only) @ surefire-reportonly-test <<<
> [INFO]
> [INFO] >>> maven-surefire-report-plugin:2.14.1:failsafe-report-only
> (report:failsafe-report-only) @ surefire-reportonly-test >>>
> [INFO]
> [INFO] <<< maven-surefire-report-plugin:2.14.1:failsafe-report-only
> (report:failsafe-report-only) @ surefire-reportonly-test <<<
> [INFO] Relativizing decoration links with respect to project URL:
> https://github.com/mfriedenhagen/pastebin
> {code}
> * When running {{mvn -e -Dmaven-surefire-plugin.version=2.15-SNAPSHOT}} the
> following output will be produced:
> {code}
> [INFO] --- maven-site-plugin:3.0:site (default-site) @
> surefire-reportonly-test ---
> [INFO] configuring report plugin org.apache.maven.plugins:maven-jxr-plugin:2.3
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-surefire-report-plugin:2.15-SNAPSHOT
> [INFO] Relativizing decoration links with respect to project URL:
> https://github.com/mfriedenhagen/pastebin
> [INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0
> skin.
> [INFO] Skipped "Test Source Xref" report, file "xref-test/index.html" already
> exists for the English version.
> [INFO] Generating "Test Source Xref" report--- maven-jxr-plugin:2.3
> [INFO] Generating "Surefire Report" report---
> maven-surefire-report-plugin:2.15-SNAPSHOT
> [INFO] Generating "Failsafe Report" report---
> maven-surefire-report-plugin:2.15-SNAPSHOT
> [INFO]
>
> {code}
> I will include the pull request in a comment.
--
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-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally
[
https://jira.codehaus.org/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325951#comment-325951
]
Cody Fyler commented on MNG-4142:
-
We are experiencing this issue with Maven 3.0.5 on Jenkins with multiple slaves.
It's kind of a nightmare.
Can we please get this at least assigned?
Here is the workaround that I came up with that in my opinion really sucks, but
it works.
http://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html#include
In this case, I use a filter to clear out the SNAPSHOT artifacts that need to
be updated. But it sucks that I have to do it. And we have a LOT of projects
where we are going to have to do something similar.
> Maven doesn't try to download a dependency when it already exists a version
> with classifier locally
> ---
>
> Key: MNG-4142
> URL: https://jira.codehaus.org/browse/MNG-4142
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9, 2.0.10, 2.1.0
> Environment: Java 5, Windows XP
>Reporter: Arnaud Heritier
>Priority: Critical
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-4142.patch, test-metadata-local-clover.zip
>
>
> When maven installs in the local repository an artifact with a classifier,
> and not the principal artifact, it won't try in a reactor to download the
> principal artifact from the remote repository.
> I created a testcase to reproduce it. It's quite simple. You unzip it and in
> the root directory you launch {code}mvn site{code}
> This build uses clover, thus it installs locally cloverified versions of
> artifacts.
> The build will fail because it doesn't find the SNAPSHOT of the module1 :
> {code}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
> th/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
> /to/file -Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1)
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> 2)
> org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> from the specified remote repositories:
> central (http://maven-proxy.groupe.generali.fr/all),
> remote-repo
> (file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
> {code}
> It's anormal because I set a "local" remote repository in the build where it
> should try to download it.
> You can validate that it is working by launching :
> {code}mvn install -f module2/pom.xml{code}
> This bug is really annoying for us. It exists for a long long time now. I
> thought it was due to a problem with metadata sent by archiva, but after
> migrating to nexus the problem always occurs.
> I don't know if the problem is in metadata or in the reactor itself. I think
> it is the second one. There are many issues opened about the reactor and
> classifiers.
> Is there some who can try if it can reproduce the error with my testcase ?
> It should be easy to create a real IT for maven with it if it is necessary.
--
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] (SUREFIRE-999) Skip phase `validate` during site-generation for `report-only` resp. `failsafe-report-only`
[
https://jira.codehaus.org/browse/SUREFIRE-999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325952#comment-325952
]
Mirko Friedenhagen commented on SUREFIRE-999:
-
As surefire is using Mojo annotations anyway, I assume JDK1.5 is given :-).
https://github.com/apache/maven-surefire/pull/24.
> Skip phase `validate` during site-generation for `report-only` resp.
> `failsafe-report-only`
>
>
> Key: SUREFIRE-999
> URL: https://jira.codehaus.org/browse/SUREFIRE-999
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.14.1, 2.15
>Reporter: Mirko Friedenhagen
>
> * We have a lot of projects in our CI system (Jenkins) where we run {{mvn
> clean deploy site-deploy}}.
> * Because of this, we do not repeat test execution again during phase
> {{site}} by defining the {{reportSet}} to include {{report-only}}.
> * However, {{report-only}} does invoke the phase {{validate}} again which
> will execute some lengthy {{enforcer}} checks.
> * I created a clone of {{maven-surefire}} where I did redefine
> {{report-only}} to not fork the lifecyle and have a small integration-test
> project
> https://github.com/mfriedenhagen/pastebin/tree/surefire-reportonly-test which
> will show the issue:
> * Running {{mvn -e}} will produce the following output:
> {code}
> [INFO] --- maven-site-plugin:3.0:site (default-site) @
> surefire-reportonly-test ---
> [INFO] configuring report plugin org.apache.maven.plugins:maven-jxr-plugin:2.3
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-surefire-report-plugin:2.14.1
> [INFO]
> [INFO] >>> maven-surefire-report-plugin:2.14.1:report-only
> (report:report-only) @ surefire-reportonly-test >>>
> [INFO]
> [INFO] <<< maven-surefire-report-plugin:2.14.1:report-only
> (report:report-only) @ surefire-reportonly-test <<<
> [INFO]
> [INFO] >>> maven-surefire-report-plugin:2.14.1:failsafe-report-only
> (report:failsafe-report-only) @ surefire-reportonly-test >>>
> [INFO]
> [INFO] <<< maven-surefire-report-plugin:2.14.1:failsafe-report-only
> (report:failsafe-report-only) @ surefire-reportonly-test <<<
> [INFO] Relativizing decoration links with respect to project URL:
> https://github.com/mfriedenhagen/pastebin
> {code}
> * When running {{mvn -e -Dmaven-surefire-plugin.version=2.15-SNAPSHOT}} the
> following output will be produced:
> {code}
> [INFO] --- maven-site-plugin:3.0:site (default-site) @
> surefire-reportonly-test ---
> [INFO] configuring report plugin org.apache.maven.plugins:maven-jxr-plugin:2.3
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-surefire-report-plugin:2.15-SNAPSHOT
> [INFO] Relativizing decoration links with respect to project URL:
> https://github.com/mfriedenhagen/pastebin
> [INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0
> skin.
> [INFO] Skipped "Test Source Xref" report, file "xref-test/index.html" already
> exists for the English version.
> [INFO] Generating "Test Source Xref" report--- maven-jxr-plugin:2.3
> [INFO] Generating "Surefire Report" report---
> maven-surefire-report-plugin:2.15-SNAPSHOT
> [INFO] Generating "Failsafe Report" report---
> maven-surefire-report-plugin:2.15-SNAPSHOT
> [INFO]
>
> {code}
> I will include the pull request in a comment.
--
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-5197) locally declared test dependency's first-generation transitive dependency version incorrectly overrides (n > 1)th-generation compile-scoped dependency version
[ https://jira.codehaus.org/browse/MNG-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325953#comment-325953 ] Ronald Chen commented on MNG-5197: -- This is a huge problem. One thing Matt didn't mention is the hamcrest-core is a compile time dependency, yet its getting overridden by a test scope transitive dependency! What is happening is Maven uses shortest path to resolve dependencies, but the problem is it also includes test scope dependencies in the shortest path resolution. So in thing3 the shortest path to hamcrest-core is though junit. This should be considered a bug because we want hamcrest-core as a COMPILE scope, but junit is declared as TEST scope I verified this is still a bug in 3.0.5 The workaround is to excludes hamcrest-core from the junit dependency. > locally declared test dependency's first-generation transitive dependency > version incorrectly overrides (n > 1)th-generation compile-scoped dependency > version > -- > > Key: MNG-5197 > URL: https://jira.codehaus.org/browse/MNG-5197 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.2.1, 3.0.3 > Environment: OSX, Windows 7 >Reporter: Matt Benson > Attachments: test-versions.tar.gz > > > This bug seems to relate to MNG-4457, MNG-4156, and potentially others, but I > have opened a new issue since nothing I found while searching could be > described in precisely the same way. > The test project I am attaching defines three modules: > thing1 > thing2 > thing3 > thing1 depends on hamcrest-core 1.2 > thing2 depends on thing1 and junit 4.10 > thing3 depends on thing2 and junit 4.10 > If you install these, you can then view the dependency trees for thing2 and > thing3 and see that thing1 correctly resolves v1.2 for hamcrest-core. > thing3, however, apparently overrides the version back to 1.1, apparently > accessed transitively via junit. > Thanks to Mark Struberg for his help in isolating this behavior! -- 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-5197) locally declared test dependency's first-generation transitive dependency version incorrectly overrides (n > 1)th-generation compile-scoped dependency version
[ https://jira.codehaus.org/browse/MNG-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325953#comment-325953 ] Ronald Chen edited comment on MNG-5197 at 5/30/13 3:48 PM: --- This is a huge problem. One thing Matt didn't mention is the hamcrest-core is a compile time dependency, yet its getting overridden by a test scope transitive dependency! What is happening is Maven uses shortest path to resolve dependencies, but the problem is it also includes test scope dependencies in the shortest path resolution. So in thing3 the shortest path to hamcrest-core is though junit. This should be considered a bug because we want hamcrest-core as a COMPILE scope, but junit is declared as TEST scope, so its transitive dependencies should be considered TEST scope and not participate in dependency resolution. I verified this is still a bug in 3.0.5 The workaround is to excludes hamcrest-core from the junit dependency. was (Author: pyrolistical): This is a huge problem. One thing Matt didn't mention is the hamcrest-core is a compile time dependency, yet its getting overridden by a test scope transitive dependency! What is happening is Maven uses shortest path to resolve dependencies, but the problem is it also includes test scope dependencies in the shortest path resolution. So in thing3 the shortest path to hamcrest-core is though junit. This should be considered a bug because we want hamcrest-core as a COMPILE scope, but the one through junit is declared as TEST scope I verified this is still a bug in 3.0.5 The workaround is to excludes hamcrest-core from the junit dependency. > locally declared test dependency's first-generation transitive dependency > version incorrectly overrides (n > 1)th-generation compile-scoped dependency > version > -- > > Key: MNG-5197 > URL: https://jira.codehaus.org/browse/MNG-5197 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.2.1, 3.0.3 > Environment: OSX, Windows 7 >Reporter: Matt Benson > Attachments: test-versions.tar.gz > > > This bug seems to relate to MNG-4457, MNG-4156, and potentially others, but I > have opened a new issue since nothing I found while searching could be > described in precisely the same way. > The test project I am attaching defines three modules: > thing1 > thing2 > thing3 > thing1 depends on hamcrest-core 1.2 > thing2 depends on thing1 and junit 4.10 > thing3 depends on thing2 and junit 4.10 > If you install these, you can then view the dependency trees for thing2 and > thing3 and see that thing1 correctly resolves v1.2 for hamcrest-core. > thing3, however, apparently overrides the version back to 1.1, apparently > accessed transitively via junit. > Thanks to Mark Struberg for his help in isolating this behavior! -- 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-5197) locally declared test dependency's first-generation transitive dependency version incorrectly overrides (n > 1)th-generation compile-scoped dependency version
[ https://jira.codehaus.org/browse/MNG-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325953#comment-325953 ] Ronald Chen edited comment on MNG-5197 at 5/30/13 3:47 PM: --- This is a huge problem. One thing Matt didn't mention is the hamcrest-core is a compile time dependency, yet its getting overridden by a test scope transitive dependency! What is happening is Maven uses shortest path to resolve dependencies, but the problem is it also includes test scope dependencies in the shortest path resolution. So in thing3 the shortest path to hamcrest-core is though junit. This should be considered a bug because we want hamcrest-core as a COMPILE scope, but the one through junit is declared as TEST scope I verified this is still a bug in 3.0.5 The workaround is to excludes hamcrest-core from the junit dependency. was (Author: pyrolistical): This is a huge problem. One thing Matt didn't mention is the hamcrest-core is a compile time dependency, yet its getting overridden by a test scope transitive dependency! What is happening is Maven uses shortest path to resolve dependencies, but the problem is it also includes test scope dependencies in the shortest path resolution. So in thing3 the shortest path to hamcrest-core is though junit. This should be considered a bug because we want hamcrest-core as a COMPILE scope, but junit is declared as TEST scope I verified this is still a bug in 3.0.5 The workaround is to excludes hamcrest-core from the junit dependency. > locally declared test dependency's first-generation transitive dependency > version incorrectly overrides (n > 1)th-generation compile-scoped dependency > version > -- > > Key: MNG-5197 > URL: https://jira.codehaus.org/browse/MNG-5197 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.2.1, 3.0.3 > Environment: OSX, Windows 7 >Reporter: Matt Benson > Attachments: test-versions.tar.gz > > > This bug seems to relate to MNG-4457, MNG-4156, and potentially others, but I > have opened a new issue since nothing I found while searching could be > described in precisely the same way. > The test project I am attaching defines three modules: > thing1 > thing2 > thing3 > thing1 depends on hamcrest-core 1.2 > thing2 depends on thing1 and junit 4.10 > thing3 depends on thing2 and junit 4.10 > If you install these, you can then view the dependency trees for thing2 and > thing3 and see that thing1 correctly resolves v1.2 for hamcrest-core. > thing3, however, apparently overrides the version back to 1.1, apparently > accessed transitively via junit. > Thanks to Mark Struberg for his help in isolating this behavior! -- 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] (MJARSIGNER-13) signing in multi-module project fails on windows
[
https://jira.codehaus.org/browse/MJARSIGNER-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325961#comment-325961
]
Alex O commented on MJARSIGNER-13:
--
+1
> signing in multi-module project fails on windows
>
>
> Key: MJARSIGNER-13
> URL: https://jira.codehaus.org/browse/MJARSIGNER-13
> Project: Maven 2.x Jar Signer Plugin
> Issue Type: Bug
>Affects Versions: 1.2
> Environment: Windows XP, android sdk
>Reporter: Anna Gadomska
> Attachments: pom.xml
>
>
> I got multi-module (6 modules) android project with .pom file and "sign"
> profile defined. When I execute with 'sign' profile:
> - in Maven 3.0.1 - it signs 3 modules and fails. when I resume the execution
> (mv -rf) it signs another 3 modules and fails again. The reason for
> failing is: [INFO] jarsigner: attempt to rename xxx.jar to xxx.jar.orig
> failed.
> - in Maven 2.2.1 - it doesn't work at all, even for first module; it returns
> "error code 1"
> However, I tried the same .pom - everything works perfectly in Linux
> (Ubuntu).
> I was afraid that it might be the issue with spaces, so I hardcoded the paths
> - the error I got from maven than was:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jarsigner-plugin:1.2:sign (signing) on project
> MyProject: Failed executing 'cmd.exe /X /C
> "C:\tools\JavaTMSEDevelopementKit\jre\..\bin\jarsigner.exe -verbose -keystore
> "C:\tmp\debug.keystore" -storepass '*' -keypass '*' xxx.jar
> '*'debugkey"' - exitcode 1 -> [Help 1]
> {noformat}
> Attaching pom file which I am using.
> Please help?
--
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-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally
[
https://jira.codehaus.org/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=325963#comment-325963
]
nodje commented on MNG-4142:
Good luck, you just have to live with it or spend the time to understand the
Maven sources by yourself.
See Martin Todorov comments for a work around.
> Maven doesn't try to download a dependency when it already exists a version
> with classifier locally
> ---
>
> Key: MNG-4142
> URL: https://jira.codehaus.org/browse/MNG-4142
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9, 2.0.10, 2.1.0
> Environment: Java 5, Windows XP
>Reporter: Arnaud Heritier
>Priority: Critical
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-4142.patch, test-metadata-local-clover.zip
>
>
> When maven installs in the local repository an artifact with a classifier,
> and not the principal artifact, it won't try in a reactor to download the
> principal artifact from the remote repository.
> I created a testcase to reproduce it. It's quite simple. You unzip it and in
> the root directory you launch {code}mvn site{code}
> This build uses clover, thus it installs locally cloverified versions of
> artifacts.
> The build will fail because it doesn't find the SNAPSHOT of the module1 :
> {code}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
> th/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
> /to/file -Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1)
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> 2)
> org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> from the specified remote repositories:
> central (http://maven-proxy.groupe.generali.fr/all),
> remote-repo
> (file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
> {code}
> It's anormal because I set a "local" remote repository in the build where it
> should try to download it.
> You can validate that it is working by launching :
> {code}mvn install -f module2/pom.xml{code}
> This bug is really annoying for us. It exists for a long long time now. I
> thought it was due to a problem with metadata sent by archiva, but after
> migrating to nexus the problem always occurs.
> I don't know if the problem is in metadata or in the reactor itself. I think
> it is the second one. There are many issues opened about the reactor and
> classifiers.
> Is there some who can try if it can reproduce the error with my testcase ?
> It should be easy to create a real IT for maven with it if it is necessary.
--
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
