[jira] [Comment Edited] (MDEPLOY-221) deploy generates wrong timestamps in maven-metadata.xml
[
https://issues.apache.org/jira/browse/MDEPLOY-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040154#comment-16040154
]
Vincent Vandenschrick edited comment on MDEPLOY-221 at 6/7/17 4:42 AM:
---
Hi Guillaume,
Unfortunately, it's not fixed. I've just tied the 3.0.0-SNAPSHOT and there is
still 1 second of difference between the metadata.xml timestamp and the
deployed file timestamp on certain artifacts. BTW, not sure it is actually
linked to the deploy plugin since the 2.8.2 works correctly on maven < 3.5.0...
Here are the logs for the failing artifact :
deployment :
Uploading:
dav:http://repository.jspresso.org/maven2-snapshots/org/jspresso/framework/jspresso-hibernate/4.3-SNAPSHOT/jspresso-hibernate-4.3-20170607.042314-72.jar
Uploaded:
dav:http://repository.jspresso.org/maven2-snapshots/org/jspresso/framework/jspresso-hibernate/4.3-SNAPSHOT/jspresso-hibernate-4.3-20170607.042314-72.jar
(78 kB at 76 kB/s)
And the failing build :
[ERROR] Failed to execute goal on project hrsample-core: Could not resolve
dependencies for project org.jspresso.hrsample:hrsample-core:jar:4.3-SNAPSHOT:
Could not find artifact
org.jspresso.framework:jspresso-hibernate:jar:4.3-20170607.042315-72 in
jspresso-snapshots-repository (http://repository.jspresso.org/maven2-snapshots)
-> [Help 1]
was (Author: vvandens):
Hi Guillaume,
Unfortunately, it's not fixed. I've just tied the 3.0.0-SNAPSHOT and there is
still 1 second of difference between the metadata.xml timestamp and the
deployed file timestamp on certain artifacts. BTW, not sure it is actually
linked to the deploy plugin since the 2.8.2 works correctly on maven < 3.5.0...
Here are the logs for the failing artifact :
deployment :
{{Uploading:
dav:http://repository.jspresso.org/maven2-snapshots/org/jspresso/framework/jspresso-hibernate/4.3-SNAPSHOT/jspresso-hibernate-4.3-20170607.042314-72.jar
Uploaded:
dav:http://repository.jspresso.org/maven2-snapshots/org/jspresso/framework/jspresso-hibernate/4.3-SNAPSHOT/jspresso-hibernate-4.3-20170607.042314-72.jar
(78 kB at 76 kB/s)}}
And the failing build :
{{[ERROR] Failed to execute goal on project hrsample-core: Could not resolve
dependencies for project org.jspresso.hrsample:hrsample-core:jar:4.3-SNAPSHOT:
Could not find artifact
org.jspresso.framework:jspresso-hibernate:jar:4.3-20170607.042315-72 in
jspresso-snapshots-repository (http://repository.jspresso.org/maven2-snapshots)
-> [Help 1]}}
> deploy generates wrong timestamps in maven-metadata.xml
> ---
>
> Key: MDEPLOY-221
> URL: https://issues.apache.org/jira/browse/MDEPLOY-221
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 2.8.2
>Reporter: Roland Illig
>
> When deploying an artifact to a Nexus server, the file {{maven-metadata.xml}}
> can end up with inconsistent timestamps.
> {noformat}
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 24 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 171 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
> (18 kB at 591 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
> (2.2 kB at 71 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
>
[jira] [Comment Edited] (MDEPLOY-221) deploy generates wrong timestamps in maven-metadata.xml
[
https://issues.apache.org/jira/browse/MDEPLOY-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040154#comment-16040154
]
Vincent Vandenschrick edited comment on MDEPLOY-221 at 6/7/17 4:40 AM:
---
Hi Guillaume,
Unfortunately, it's not fixed. I've just tied the 3.0.0-SNAPSHOT and there is
still 1 second of difference between the metadata.xml timestamp and the
deployed file timestamp on certain artifacts. BTW, not sure it is actually
linked to the deploy plugin since the 2.8.2 works correctly on maven < 3.5.0...
Here are the logs for the failing artifact :
deployment :
{{
Uploading:
dav:http://repository.jspresso.org/maven2-snapshots/org/jspresso/framework/jspresso-hibernate/4.3-SNAPSHOT/jspresso-hibernate-4.3-20170607.042314-72.jar
Uploaded:
dav:http://repository.jspresso.org/maven2-snapshots/org/jspresso/framework/jspresso-hibernate/4.3-SNAPSHOT/jspresso-hibernate-4.3-20170607.042314-72.jar
(78 kB at 76 kB/s)
}}
And the failing build :
{{
[ERROR] Failed to execute goal on project hrsample-core: Could not resolve
dependencies for project org.jspresso.hrsample:hrsample-core:jar:4.3-SNAPSHOT:
Could not find artifact
org.jspresso.framework:jspresso-hibernate:jar:4.3-20170607.042315-72 in
jspresso-snapshots-repository (http://repository.jspresso.org/maven2-snapshots)
-> [Help 1]
}}
was (Author: vvandens):
Hi Guillaume,
Unfortunately, it's not fixed. I've just tied the 3.0.0-SNAPSHOT and there is
still 1 second of difference between the metadata.xml timestamp and the
deployed file timestamp on certain artifacts. BTW, not sure it is actually
linked to the deploy plugin since the 2.8.2 works correctly on maven < 3.5.0...
Here are the logs for the failing artifact :
deployment :
{{monospaced}}
Uploading:
dav:http://repository.jspresso.org/maven2-snapshots/org/jspresso/framework/jspresso-hibernate/4.3-SNAPSHOT/jspresso-hibernate-4.3-20170607.042314-72.jar
Uploaded:
dav:http://repository.jspresso.org/maven2-snapshots/org/jspresso/framework/jspresso-hibernate/4.3-SNAPSHOT/jspresso-hibernate-4.3-20170607.042314-72.jar
(78 kB at 76 kB/s)
{{monospaced}}
And the failing build :
{{monospaced}}
[ERROR] Failed to execute goal on project hrsample-core: Could not resolve
dependencies for project org.jspresso.hrsample:hrsample-core:jar:4.3-SNAPSHOT:
Could not find artifact
org.jspresso.framework:jspresso-hibernate:jar:4.3-20170607.042315-72 in
jspresso-snapshots-repository (http://repository.jspresso.org/maven2-snapshots)
-> [Help 1]
{{monospaced}}
> deploy generates wrong timestamps in maven-metadata.xml
> ---
>
> Key: MDEPLOY-221
> URL: https://issues.apache.org/jira/browse/MDEPLOY-221
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 2.8.2
>Reporter: Roland Illig
>
> When deploying an artifact to a Nexus server, the file {{maven-metadata.xml}}
> can end up with inconsistent timestamps.
> {noformat}
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 24 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 171 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
> (18 kB at 591 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
> (2.2 kB at 71 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
>
[jira] [Comment Edited] (MDEPLOY-221) deploy generates wrong timestamps in maven-metadata.xml
[
https://issues.apache.org/jira/browse/MDEPLOY-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040154#comment-16040154
]
Vincent Vandenschrick edited comment on MDEPLOY-221 at 6/7/17 4:41 AM:
---
Hi Guillaume,
Unfortunately, it's not fixed. I've just tied the 3.0.0-SNAPSHOT and there is
still 1 second of difference between the metadata.xml timestamp and the
deployed file timestamp on certain artifacts. BTW, not sure it is actually
linked to the deploy plugin since the 2.8.2 works correctly on maven < 3.5.0...
Here are the logs for the failing artifact :
deployment :
{{Uploading:
dav:http://repository.jspresso.org/maven2-snapshots/org/jspresso/framework/jspresso-hibernate/4.3-SNAPSHOT/jspresso-hibernate-4.3-20170607.042314-72.jar
Uploaded:
dav:http://repository.jspresso.org/maven2-snapshots/org/jspresso/framework/jspresso-hibernate/4.3-SNAPSHOT/jspresso-hibernate-4.3-20170607.042314-72.jar
(78 kB at 76 kB/s)}}
And the failing build :
{{[ERROR] Failed to execute goal on project hrsample-core: Could not resolve
dependencies for project org.jspresso.hrsample:hrsample-core:jar:4.3-SNAPSHOT:
Could not find artifact
org.jspresso.framework:jspresso-hibernate:jar:4.3-20170607.042315-72 in
jspresso-snapshots-repository (http://repository.jspresso.org/maven2-snapshots)
-> [Help 1]}}
was (Author: vvandens):
Hi Guillaume,
Unfortunately, it's not fixed. I've just tied the 3.0.0-SNAPSHOT and there is
still 1 second of difference between the metadata.xml timestamp and the
deployed file timestamp on certain artifacts. BTW, not sure it is actually
linked to the deploy plugin since the 2.8.2 works correctly on maven < 3.5.0...
Here are the logs for the failing artifact :
deployment :
{{
Uploading:
dav:http://repository.jspresso.org/maven2-snapshots/org/jspresso/framework/jspresso-hibernate/4.3-SNAPSHOT/jspresso-hibernate-4.3-20170607.042314-72.jar
Uploaded:
dav:http://repository.jspresso.org/maven2-snapshots/org/jspresso/framework/jspresso-hibernate/4.3-SNAPSHOT/jspresso-hibernate-4.3-20170607.042314-72.jar
(78 kB at 76 kB/s)
}}
And the failing build :
{{
[ERROR] Failed to execute goal on project hrsample-core: Could not resolve
dependencies for project org.jspresso.hrsample:hrsample-core:jar:4.3-SNAPSHOT:
Could not find artifact
org.jspresso.framework:jspresso-hibernate:jar:4.3-20170607.042315-72 in
jspresso-snapshots-repository (http://repository.jspresso.org/maven2-snapshots)
-> [Help 1]
}}
> deploy generates wrong timestamps in maven-metadata.xml
> ---
>
> Key: MDEPLOY-221
> URL: https://issues.apache.org/jira/browse/MDEPLOY-221
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 2.8.2
>Reporter: Roland Illig
>
> When deploying an artifact to a Nexus server, the file {{maven-metadata.xml}}
> can end up with inconsistent timestamps.
> {noformat}
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 24 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 171 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
> (18 kB at 591 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
> (2.2 kB at 71 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
>
[jira] [Commented] (MDEPLOY-221) deploy generates wrong timestamps in maven-metadata.xml
[
https://issues.apache.org/jira/browse/MDEPLOY-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040154#comment-16040154
]
Vincent Vandenschrick commented on MDEPLOY-221:
---
Hi Guillaume,
Unfortunately, it's not fixed. I've just tied the 3.0.0-SNAPSHOT and there is
still 1 second of difference between the metadata.xml timestamp and the
deployed file timestamp on certain artifacts. BTW, not sure it is actually
linked to the deploy plugin since the 2.8.2 works correctly on maven < 3.5.0...
Here are the logs for the failing artifact :
deployment :
{{monospaced}}
Uploading:
dav:http://repository.jspresso.org/maven2-snapshots/org/jspresso/framework/jspresso-hibernate/4.3-SNAPSHOT/jspresso-hibernate-4.3-20170607.042314-72.jar
Uploaded:
dav:http://repository.jspresso.org/maven2-snapshots/org/jspresso/framework/jspresso-hibernate/4.3-SNAPSHOT/jspresso-hibernate-4.3-20170607.042314-72.jar
(78 kB at 76 kB/s)
{{monospaced}}
And the failing build :
{{monospaced}}
[ERROR] Failed to execute goal on project hrsample-core: Could not resolve
dependencies for project org.jspresso.hrsample:hrsample-core:jar:4.3-SNAPSHOT:
Could not find artifact
org.jspresso.framework:jspresso-hibernate:jar:4.3-20170607.042315-72 in
jspresso-snapshots-repository (http://repository.jspresso.org/maven2-snapshots)
-> [Help 1]
{{monospaced}}
> deploy generates wrong timestamps in maven-metadata.xml
> ---
>
> Key: MDEPLOY-221
> URL: https://issues.apache.org/jira/browse/MDEPLOY-221
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 2.8.2
>Reporter: Roland Illig
>
> When deploying an artifact to a Nexus server, the file {{maven-metadata.xml}}
> can end up with inconsistent timestamps.
> {noformat}
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 24 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 171 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
> (18 kB at 591 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
> (2.2 kB at 71 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 59 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 43 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 33 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 40 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-sources.jar
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-sources.jar
> (12 kB at 386 kB/s)
> [INFO]
[jira] [Commented] (SUREFIRE-1383) dependenciesToScan Does Not Leverage Classpath Elements
[ https://issues.apache.org/jira/browse/SUREFIRE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16040005#comment-16040005 ] Owen Farrell commented on SUREFIRE-1383: The maven-compiler-plugin seems to handle this issue just fine when building a list of classpathEntries. I'm not a Maven API SME by any means, so the below is a bit of a guess in terms of approach: * AbstractSurefireMojo.scanDependencies needs to inspect projects on the MavenSession * For each scanned dependency that is found in the session ** Translate the dependency in to a MavenProject instance (by leveraging the session?) ** Get the build output directory for the project ** Create new directory scanner that wraps the build output directory of the project > dependenciesToScan Does Not Leverage Classpath Elements > > > Key: SUREFIRE-1383 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1383 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20 >Reporter: Owen Farrell > Fix For: 3.0, 2.20.1 > > Attachments: scanned-dependencies-sample.zip > > > The configuration attribute relies solely on installed > artifacts. This is an issue when the targeted dependencies were built as part > of the current session. The net result is that stale artifacts are used (i.e. > if the dependency has changed since it was last installed) or the tests are > not executed at all (if the dependency has not been previously installed. > Attached is a sample project that illustrates this issue: > Given I have a multi-module project >And the first module built includes test classes as part of the project > artifact >And subsequent modules scan the first for unit tests to execute > When I execute the _*test*_ goal (prior to any install) > Then the build should succeed >And tests should be executed with each module -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SUREFIRE-1383) dependenciesToScan Does Not Leverage Classpath Elements
Owen Farrell created SUREFIRE-1383: -- Summary: dependenciesToScan Does Not Leverage Classpath Elements Key: SUREFIRE-1383 URL: https://issues.apache.org/jira/browse/SUREFIRE-1383 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.20 Reporter: Owen Farrell Fix For: 3.0, 2.20.1 Attachments: scanned-dependencies-sample.zip The configuration attribute relies solely on installed artifacts. This is an issue when the targeted dependencies were built as part of the current session. The net result is that stale artifacts are used (i.e. if the dependency has changed since it was last installed) or the tests are not executed at all (if the dependency has not been previously installed. Attached is a sample project that illustrates this issue: Given I have a multi-module project And the first module built includes test classes as part of the project artifact And subsequent modules scan the first for unit tests to execute When I execute the _*test*_ goal (prior to any install) Then the build should succeed And tests should be executed with each module -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (SUREFIRE-1370) Build failed in Jenkins with error :The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
[ https://issues.apache.org/jira/browse/SUREFIRE-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1370. -- Resolution: Duplicate SUREFIRE-1302 will fix this issue in version 2.20.1. > Build failed in Jenkins with error :The forked VM terminated without properly > saying goodbye. VM crash or System.exit called? > - > > Key: SUREFIRE-1370 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1370 > Project: Maven Surefire > Issue Type: Bug >Reporter: Vijay >Assignee: Tibor Digana > Attachments: 2017-05-09T08-08-44_247-jvmRun1.dumpstream, > failureLogs.txt, NewfailureLogs.txt > > > Build failed in Jenkins with error :The forked VM terminated without properly > saying goodbye. VM crash or System.exit called? > Tried on version 2.19.1 and 2.20 ,both the versions having same problem and > This problem is very frequently occured , see attached logs for more details . > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (SUREFIRE-1382) OutOfMemoryError occurs when JUnit 5 test fails
[
https://issues.apache.org/jira/browse/SUREFIRE-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039703#comment-16039703
]
Tibor Digana edited comment on SUREFIRE-1382 at 6/6/17 9:43 PM:
[~wissenstein]
I saw this bug in JUnit 5 originally in JUnit group. You have to collaborate
with junit team. We work on release of 2.20.1.
was (Author: tibor17):
[~wissenstein]
I saw this bug in JUnit 5 originally in JUnit groupp. You have to collaborate
with junit team. We work on release of 2.20.1.
> OutOfMemoryError occurs when JUnit 5 test fails
> ---
>
> Key: SUREFIRE-1382
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1382
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.20
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: C:\prg\apache-maven-3.3.9\bin\..
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_102\jre
> Default locale: en_US, platform encoding: Cp1251
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"
>Reporter: Oleksij Lupandin
>
> h4. Steps to reproduce
> # Check out project "maven-surefire2_20-junit5" from
> https://wissenst...@gitlab.com/wissenstein/maven-surefire2_20-junit5.git.
> # Go to the project root (where pom.xml is).
> # Run the following command: {code}mvn -Psurefire2_19_1 clean test{code}
> The project is tested using Surefire Maven plugin version 2.19.1. At the end
> of the output you can see:
> {code}---
> T E S T S
> ---
> Running com.wissenstein.mavensurefirejunit.SimplisticTest
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.073 sec <<<
> FAILURE! - in com.wissenstein.mavensurefirejunit.SimplisticTest
> shouldDeliberatelyFail() Time elapsed: 0.021 sec <<< FAILURE!
> org.opentest4j.AssertionFailedError: Test deliberately failed
> at
> com.wissenstein.mavensurefirejunit.SimplisticTest.shouldDeliberatelyFail(SimplisticTest.java:11)
> Results :
> Failed tests:
> SimplisticTest.shouldDeliberatelyFail:11 Test deliberately failed
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 4.583 s
> [INFO] Finished at: 2017-06-06T16:57:35+02:00
> [INFO] Final Memory: 16M/264M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on
> project maven-surefire2_20-junit5: There are test failures.
> [ERROR]
> [ERROR] Please refer to
> C:\projects\surefire\maven-surefire2_20-junit5\target\surefire-reports for
> the individual test results.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [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/MojoFailureException{code}
> # Run the following command: {code}mvn -Psurefire2_20 clean test{code}
> The project is tested using Surefire Maven plugin version 2.20.
> h4. Actual result
> At the end of the output you can see: {code}[INFO]
> ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running com.wissenstein.mavensurefirejunit.SimplisticTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 6.061 s
> [INFO] Finished at: 2017-06-06T17:03:52+02:00
> [INFO] Final Memory: 17M/3028M
> [INFO]
>
> [ERROR] Java heap space -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [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/OutOfMemoryError{code}
> The stack trace is as follows: {code}java.lang.OutOfMemoryError: Java heap
[jira] [Commented] (SUREFIRE-1382) OutOfMemoryError occurs when JUnit 5 test fails
[
https://issues.apache.org/jira/browse/SUREFIRE-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039703#comment-16039703
]
Tibor Digana commented on SUREFIRE-1382:
[~wissenstein]
I saw this bug in JUnit 5 originally in JUnit groupp. You have to collaborate
with junit team. We work on release of 2.20.1.
> OutOfMemoryError occurs when JUnit 5 test fails
> ---
>
> Key: SUREFIRE-1382
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1382
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.20
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: C:\prg\apache-maven-3.3.9\bin\..
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_102\jre
> Default locale: en_US, platform encoding: Cp1251
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"
>Reporter: Oleksij Lupandin
>
> h4. Steps to reproduce
> # Check out project "maven-surefire2_20-junit5" from
> https://wissenst...@gitlab.com/wissenstein/maven-surefire2_20-junit5.git.
> # Go to the project root (where pom.xml is).
> # Run the following command: {code}mvn -Psurefire2_19_1 clean test{code}
> The project is tested using Surefire Maven plugin version 2.19.1. At the end
> of the output you can see:
> {code}---
> T E S T S
> ---
> Running com.wissenstein.mavensurefirejunit.SimplisticTest
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.073 sec <<<
> FAILURE! - in com.wissenstein.mavensurefirejunit.SimplisticTest
> shouldDeliberatelyFail() Time elapsed: 0.021 sec <<< FAILURE!
> org.opentest4j.AssertionFailedError: Test deliberately failed
> at
> com.wissenstein.mavensurefirejunit.SimplisticTest.shouldDeliberatelyFail(SimplisticTest.java:11)
> Results :
> Failed tests:
> SimplisticTest.shouldDeliberatelyFail:11 Test deliberately failed
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 4.583 s
> [INFO] Finished at: 2017-06-06T16:57:35+02:00
> [INFO] Final Memory: 16M/264M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on
> project maven-surefire2_20-junit5: There are test failures.
> [ERROR]
> [ERROR] Please refer to
> C:\projects\surefire\maven-surefire2_20-junit5\target\surefire-reports for
> the individual test results.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [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/MojoFailureException{code}
> # Run the following command: {code}mvn -Psurefire2_20 clean test{code}
> The project is tested using Surefire Maven plugin version 2.20.
> h4. Actual result
> At the end of the output you can see: {code}[INFO]
> ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running com.wissenstein.mavensurefirejunit.SimplisticTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 6.061 s
> [INFO] Finished at: 2017-06-06T17:03:52+02:00
> [INFO] Final Memory: 17M/3028M
> [INFO]
>
> [ERROR] Java heap space -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [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/OutOfMemoryError{code}
> The stack trace is as follows: {code}java.lang.OutOfMemoryError: Java heap
> space
> at java.util.Arrays.copyOf(Arrays.java:3332)
> at
> java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
> at
>
[jira] [Closed] (MANTRUN-172) Properties passed to Maven as -D don't get passed to invocations when a profile sets the same property
[ https://issues.apache.org/jira/browse/MANTRUN-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Boué closed MANTRUN-172. -- Resolution: Fixed Assignee: Guillaume Boué Fix Version/s: 3.0.0 > Properties passed to Maven as -D don't get passed to invocations when a > profile sets the same property > > > Key: MANTRUN-172 > URL: https://issues.apache.org/jira/browse/MANTRUN-172 > Project: Maven Antrun Plugin > Issue Type: Bug >Affects Versions: 1.7 >Reporter: Derek Lewis >Assignee: Guillaume Boué > Fix For: 3.0.0 > > Attachments: maven-antrun-plugin-bug.zip > > > When I invoke Maven as follows: > mvn package -Dmy.test.property="from commandline" -Ptest-profile > Setting my.test.property on the command line, I expect to see the following > output from the testcase: > [echo] pom.xml: ptest = from commandline > [echo] pom.xml: my.test.property = from commandline > [echo] build.xml: ptest = from commandline > [echo] build.xml: my.test.property = from commandline > But instead I see: > [echo] pom.xml: ptest = from commandline > [echo] pom.xml: my.test.property = from commandline > [echo] build.xml: ptest = from commandline > [echo] build.xml: my.test.property = from profile > It looks like the task is causing properties set on the command line to > not be inherited. > When run without -Ptest-profile, the expected output is seen. The comments > on MANTRUN-121 would seem to imply that properties set on the commandline > should always be passed to sub builds, regardless of the value of the > inheritAll property. > I've tested with a profile in the pom as well as in settings.xml, and the > same behavior is observed regardless of where the profile is, so long as it > is activated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MANTRUN-203) Upgrade to maven-plugins 30
[ https://issues.apache.org/jira/browse/MANTRUN-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Boué closed MANTRUN-203. -- Resolution: Fixed Fix Version/s: 3.0.0 > Upgrade to maven-plugins 30 > --- > > Key: MANTRUN-203 > URL: https://issues.apache.org/jira/browse/MANTRUN-203 > Project: Maven Antrun Plugin > Issue Type: Improvement >Affects Versions: 1.8 >Reporter: Guillaume Boué >Assignee: Guillaume Boué >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (MANTRUN-181) AttachArtifact task does not work in external Ant build file
[
https://issues.apache.org/jira/browse/MANTRUN-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Boué closed MANTRUN-181.
--
Resolution: Fixed
Assignee: Guillaume Boué
Fix Version/s: 3.0.0
> AttachArtifact task does not work in external Ant build file
>
>
> Key: MANTRUN-181
> URL: https://issues.apache.org/jira/browse/MANTRUN-181
> Project: Maven Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.5, 1.6, 1.7
>Reporter: Anton Khitrenovich
>Assignee: Guillaume Boué
> Fix For: 3.0.0
>
> Attachments: MyProject.zip
>
>
> AttachArtifact task fails with an error if used in external Ant build file:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:1.7:run (call-build) on project
> my-test-project: An Ant BuildException has occured: The following error
> occurred while executing this line:
> [ERROR] C:\...\MyProject\build.xml:5: Maven project reference not found:
> maven.project
> [ERROR] around Ant part .. @
> 4:47 in C:\...\MyProject\target\antrun\build-main.xml
> {code}
> Setting {{inheritRefs="true"}} eliminates the error, but even then the
> artifact is not attached.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MANTRUN-202) Fail the build when deprecated parameters tasks, sourceRoot or testSourceRoot are used
[
https://issues.apache.org/jira/browse/MANTRUN-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Boué closed MANTRUN-202.
--
Resolution: Fixed
Fix Version/s: 3.0.0
> Fail the build when deprecated parameters tasks, sourceRoot or testSourceRoot
> are used
> --
>
> Key: MANTRUN-202
> URL: https://issues.apache.org/jira/browse/MANTRUN-202
> Project: Maven Antrun Plugin
> Issue Type: Improvement
>Affects Versions: 1.8
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
> Fix For: 3.0.0
>
>
> With the plugin migration to Maven 3, deprecated parameters should fail the
> build when used, in preparation of their future removal.
> Additionally, the deprecated format for referencing the project dependencies
> as Ant properties with
> {{maven.dependency.groupId.artifactId\[.classifier\].type.path}} should not
> be supported anymore. The format {{groupId:artifactId:type\[:classifier\]}}
> should be used instead.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MANTRUN-201) Migrate plugin to Maven 3.0
[ https://issues.apache.org/jira/browse/MANTRUN-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Boué closed MANTRUN-201. -- Resolution: Fixed Fix Version/s: 3.0.0 > Migrate plugin to Maven 3.0 > --- > > Key: MANTRUN-201 > URL: https://issues.apache.org/jira/browse/MANTRUN-201 > Project: Maven Antrun Plugin > Issue Type: Improvement >Affects Versions: 1.8 >Reporter: Guillaume Boué >Assignee: Guillaume Boué > Fix For: 3.0.0 > > > Migrate plugin as described at > https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MDEPLOY-221) deploy generates wrong timestamps in maven-metadata.xml
[
https://issues.apache.org/jira/browse/MDEPLOY-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039531#comment-16039531
]
Guillaume Boué commented on MDEPLOY-221:
Can someone try using the latest 3.0.0-SNAPSHOT of the Deploy Plugin? There
were major changes in it and it is likely to already be solved. The snapshot
repository to use is
{{https://repository.apache.org/content/repositories/snapshots}}.
> deploy generates wrong timestamps in maven-metadata.xml
> ---
>
> Key: MDEPLOY-221
> URL: https://issues.apache.org/jira/browse/MDEPLOY-221
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 2.8.2
>Reporter: Roland Illig
>
> When deploying an artifact to a Nexus server, the file {{maven-metadata.xml}}
> can end up with inconsistent timestamps.
> {noformat}
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 24 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 171 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
> (18 kB at 591 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
> (2.2 kB at 71 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 59 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 43 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 33 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 40 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-sources.jar
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-sources.jar
> (12 kB at 386 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 59 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 65 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Uploaded:
>
[jira] [Updated] (SUREFIRE-1382) OutOfMemoryError occurs when JUnit 5 test fails
[
https://issues.apache.org/jira/browse/SUREFIRE-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleksij Lupandin updated SUREFIRE-1382:
---
Description:
h4. Steps to reproduce
# Check out project "maven-surefire2_20-junit5" from
https://wissenst...@gitlab.com/wissenstein/maven-surefire2_20-junit5.git.
# Go to the project root (where pom.xml is).
# Run the following command: {code}mvn -Psurefire2_19_1 clean test{code}
The project is tested using Surefire Maven plugin version 2.19.1. At the end of
the output you can see:
{code}---
T E S T S
---
Running com.wissenstein.mavensurefirejunit.SimplisticTest
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.073 sec <<<
FAILURE! - in com.wissenstein.mavensurefirejunit.SimplisticTest
shouldDeliberatelyFail() Time elapsed: 0.021 sec <<< FAILURE!
org.opentest4j.AssertionFailedError: Test deliberately failed
at
com.wissenstein.mavensurefirejunit.SimplisticTest.shouldDeliberatelyFail(SimplisticTest.java:11)
Results :
Failed tests:
SimplisticTest.shouldDeliberatelyFail:11 Test deliberately failed
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 4.583 s
[INFO] Finished at: 2017-06-06T16:57:35+02:00
[INFO] Final Memory: 16M/264M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on
project maven-surefire2_20-junit5: There are test failures.
[ERROR]
[ERROR] Please refer to
C:\projects\surefire\maven-surefire2_20-junit5\target\surefire-reports for the
individual test results.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[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/MojoFailureException{code}
# Run the following command: {code}mvn -Psurefire2_20 clean test{code}
The project is tested using Surefire Maven plugin version 2.20.
h4. Actual result
At the end of the output you can see: {code}[INFO]
---
[INFO] T E S T S
[INFO] ---
[INFO] Running com.wissenstein.mavensurefirejunit.SimplisticTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 6.061 s
[INFO] Finished at: 2017-06-06T17:03:52+02:00
[INFO] Final Memory: 17M/3028M
[INFO]
[ERROR] Java heap space -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[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/OutOfMemoryError{code}
The stack trace is as follows: {code}java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3332)
at
java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
at java.lang.StringBuilder.append(StringBuilder.java:136)
at
org.apache.maven.plugin.surefire.booterclient.output.MultipleFailureException.getLocalizedMessage(MultipleFailureException.java:52)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter$CloseableCloser.run(ForkStarter.java:200)
at
org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineUtils$1.call(CommandLineUtils.java:282)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:626)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
at
[jira] [Created] (SUREFIRE-1382) OutOfMemoryError occurs when JUnit 5 test fails
Oleksij Lupandin created SUREFIRE-1382:
--
Summary: OutOfMemoryError occurs when JUnit 5 test fails
Key: SUREFIRE-1382
URL: https://issues.apache.org/jira/browse/SUREFIRE-1382
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.20
Environment: Apache Maven 3.3.9
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
Maven home: C:\prg\apache-maven-3.3.9\bin\..
Java version: 1.8.0_102, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_102\jre
Default locale: en_US, platform encoding: Cp1251
OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"
Reporter: Oleksij Lupandin
h4. Steps to reproduce
# Check out project "maven-surefire2_20-junit5" from
https://wissenst...@gitlab.com/wissenstein/maven-surefire2_20-junit5.git.
# Go to the project root (where pom.xml is).
# Run the following command: {code}mvn -Psurefire2_19_1 clean test{code}
The project is tested using Surefire Maven plugin version 2.19.1. At the end of
the output you can see:
{code}---
T E S T S
---
Running com.wissenstein.mavensurefirejunit.SimplisticTest
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.073 sec <<<
FAILURE! - in com.wissenstein.mavensurefirejunit.SimplisticTest
shouldDeliberatelyFail() Time elapsed: 0.021 sec <<< FAILURE!
org.opentest4j.AssertionFailedError: Test deliberately failed
at
com.wissenstein.mavensurefirejunit.SimplisticTest.shouldDeliberatelyFail(SimplisticTest.java:11)
Results :
Failed tests:
SimplisticTest.shouldDeliberatelyFail:11 Test deliberately failed
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 4.583 s
[INFO] Finished at: 2017-06-06T16:57:35+02:00
[INFO] Final Memory: 16M/264M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on
project maven-surefire2_20-junit5: There are test failures.
[ERROR]
[ERROR] Please refer to
C:\projects\surefire\maven-surefire2_20-junit5\target\surefire-reports for the
individual test results.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[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/MojoFailureException{code}
# Run the following command: {code}mvn -Psurefire2_20 clean test{code}
The project is tested using Surefire Maven plugin version 2.20.
h4. Actual result
At the end of the output you can see: {code}[INFO]
---
[INFO] T E S T S
[INFO] ---
[INFO] Running com.wissenstein.mavensurefirejunit.SimplisticTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 6.061 s
[INFO] Finished at: 2017-06-06T17:03:52+02:00
[INFO] Final Memory: 17M/3028M
[INFO]
[ERROR] Java heap space -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[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/OutOfMemoryError{code}
The stack trace is as follows: {code}java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3332)
at
java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
at java.lang.StringBuilder.append(StringBuilder.java:136)
at
org.apache.maven.plugin.surefire.booterclient.output.MultipleFailureException.getLocalizedMessage(MultipleFailureException.java:52)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter$CloseableCloser.run(ForkStarter.java:200)
at
org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineUtils$1.call(CommandLineUtils.java:282)
at
[jira] [Comment Edited] (MNG-5315) Artifact resolution sporadically fails in parallel builds
[
https://issues.apache.org/jira/browse/MNG-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038928#comment-16038928
]
Bob Tiernay edited comment on MNG-5315 at 6/6/17 1:57 PM:
--
[~hboutemy] Is this still an open issue or was this fixed as a consequence of
[MNG-6110|https://issues.apache.org/jira/browse/MNG-6110] and can now be closed?
was (Author: btiernay):
[~hboutemy] Is this still an open issue or was this fixed as a consequnce of
https://issues.apache.org/jira/browse/MNG-6110 and can now be closed?
> Artifact resolution sporadically fails in parallel builds
> -
>
> Key: MNG-5315
> URL: https://issues.apache.org/jira/browse/MNG-5315
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.4
>Reporter: Ivan Dubrov
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: MNG-5315-3.0.x.patch, MNG-5315-3.1.2-SNAPSHOT.patch
>
>
> 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
[jira] [Commented] (MNG-5315) Artifact resolution sporadically fails in parallel builds
[
https://issues.apache.org/jira/browse/MNG-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038928#comment-16038928
]
Bob Tiernay commented on MNG-5315:
--
[~hboutemy] Is this still an open issue or was this fixed as a consequnce of
https://issues.apache.org/jira/browse/MNG-6110 and can now be closed?
> Artifact resolution sporadically fails in parallel builds
> -
>
> Key: MNG-5315
> URL: https://issues.apache.org/jira/browse/MNG-5315
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.4
>Reporter: Ivan Dubrov
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: MNG-5315-3.0.x.patch, MNG-5315-3.1.2-SNAPSHOT.patch
>
>
> 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
>
[jira] [Commented] (SUREFIRE-1331) Bump version number
[ https://issues.apache.org/jira/browse/SUREFIRE-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038718#comment-16038718 ] ASF GitHub Bot commented on SUREFIRE-1331: -- Github user britter commented on the issue: https://github.com/apache/maven-surefire/pull/141 @Tibor17 so we can merge this to 3.0-rc1 branch? Than the branch will have the correct SNAPSHOT version. > Bump version number > --- > > Key: SUREFIRE-1331 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1331 > Project: Maven Surefire > Issue Type: Task >Reporter: Benedikt Ritter > Fix For: 3.0-RC1 > > > Currently the version in 3.0-rc1 branch is 2.19.2-SNAPSHOT. We should bump it > to 3.0.0-SNAPSHOT. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1330) JUnit 5 surefire-provider code donation
[ https://issues.apache.org/jira/browse/SUREFIRE-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038704#comment-16038704 ] ASF GitHub Bot commented on SUREFIRE-1330: -- Github user britter commented on the issue: https://github.com/apache/maven-surefire/pull/146 Thank you! > JUnit 5 surefire-provider code donation > --- > > Key: SUREFIRE-1330 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1330 > Project: Maven Surefire > Issue Type: Task >Reporter: Benedikt Ritter > Fix For: 3.0-RC1 > > Attachments: junit-platform-surefire-provider.zip > > > The JUnit team wishes to contribute their surefire provider implementation > for JUnit 5 to the Maven team. > The code is currently located at GitHub: > https://github.com/junit-team/junit5/tree/master/junit-platform-surefire-provider > They have recently relicensed the code under terms of Apache License 2.0: > https://github.com/junit-team/junit5/issues/541 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1370) Build failed in Jenkins with error :The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
[ https://issues.apache.org/jira/browse/SUREFIRE-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038670#comment-16038670 ] Vijay commented on SUREFIRE-1370: - Not seen any OutOfMemoryError. we are not using configuration parameter parallel. We are not using the provider surefire-junit47. I am not able to find any logs with hs_err*.log > Build failed in Jenkins with error :The forked VM terminated without properly > saying goodbye. VM crash or System.exit called? > - > > Key: SUREFIRE-1370 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1370 > Project: Maven Surefire > Issue Type: Bug >Reporter: Vijay >Assignee: Tibor Digana > Attachments: 2017-05-09T08-08-44_247-jvmRun1.dumpstream, > failureLogs.txt, NewfailureLogs.txt > > > Build failed in Jenkins with error :The forked VM terminated without properly > saying goodbye. VM crash or System.exit called? > Tried on version 2.19.1 and 2.20 ,both the versions having same problem and > This problem is very frequently occured , see attached logs for more details . > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MDEP-569) copy fails on artifacts previously downloaded via get from repo specified via CLI
[
https://issues.apache.org/jira/browse/MDEP-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038639#comment-16038639
]
Tom Wieczorek commented on MDEP-569:
Sure, if you have a project. In my particular use case, the plugin in is used a
scripting context where no POM file is available to add the repo to. That's why
I asked. I'm currently looking into the sources and try to figure out if I can
maybe contribute a patch.
> copy fails on artifacts previously downloaded via get from repo specified via
> CLI
> -
>
> Key: MDEP-569
> URL: https://issues.apache.org/jira/browse/MDEP-569
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: copy, get
>Affects Versions: 3.0.1
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z)
> Maven home: /usr/share/maven
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8-openjdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.8.0-52-generic", arch: "amd64", family: "unix"
>Reporter: Tom Wieczorek
> Attachments: dependency-copy-problem-output.txt
>
>
> {{dependency:copy}} fails to copy artifacts that were previously downloaded
> via {{dependency:get}} from a remote repository that has been specified on
> the command line. The error message is:
> bq. The POM for artifact is missing, no dependency information available
> and later on
> bq. Failed to execute goal dependency:copy (default-cli) on project
> standalone-pom: Unable to find/resolve artifact. Failure to find artifact in
> https://repo.maven.apache.org/maven2 was cached in the local repository,
> resolution will not be reattempted until the update interval of central has
> elapsed or updates are forced
> But: {{dependency:get}} actually succeeded and the artifact and its POM are
> in the local repo.
> {code:none|title=Reproducing shell snippet}
> mvn -version
> mvn org.apache.maven.plugins:maven-dependency-plugin:3.0.1:get \
> org.apache.maven.plugins:maven-dependency-plugin:3.0.1:copy \
> -DremoteRepositories=http://packages.confluent.io/maven/ \
> -Dartifact=io.confluent:kafka-schema-registry:3.1.1
> ls -la ~/.m2/repository/io/confluent/kafka-schema-registry/3.1.1
> {code}
> I've attached the output of the above test snippets.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MENFORCER-270) option to forbid plugin snapshot versions only when releasing
[ https://issues.apache.org/jira/browse/MENFORCER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16038637#comment-16038637 ] Joerg Schaible commented on MENFORCER-270: -- You already have this. The release plugin activates a profile (by default "release", but that can be configured) when it runs a release build. So simply configure this enforcer rule in that special profile. > option to forbid plugin snapshot versions only when releasing > - > > Key: MENFORCER-270 > URL: https://issues.apache.org/jira/browse/MENFORCER-270 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 1.4.1 >Reporter: Gruust >Priority: Minor > > Basically, it would be nice if plugin versions would be treated similar to > regular dependencies, ie. have a standard rule that only complains about > snapshot plugin versions when trying to release the project. That's > especially helpful when having maven plugin sub-modules as part of a larger > multi-module project. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MENFORCER-271) Dependency convergence rule is very slow in larger projects
[
https://issues.apache.org/jira/browse/MENFORCER-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MENFORCER-271:
---
Attachment: (was: visualvm.PNG)
> Dependency convergence rule is very slow in larger projects
> ---
>
> Key: MENFORCER-271
> URL: https://issues.apache.org/jira/browse/MENFORCER-271
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: C:\Program Files\apache-maven-3.3.9
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.8.0_102\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Falko Modler
> Attachments: visualvm.PNG, visualvm_settings.PNG
>
>
> I noticed that DependencyConvergence can take up to 10 seconds or even more
> in modules with almost 300 direct and transitive dependencies (reported by
> {{dependency:tree}}).
> These modules are part of a JEE project based on JBoss EAP 6.4 which imports
> a couple of EAP BOMs. Unfortunately I am not allowed to share this project.
> I profiled the rule via VisualVM and these are the top 5 hotspots:
> !visualvm.PNG!
> The number of {{parseVersion}} calls seems excessive.
> See attached {{visualvm_settings.xml}} for reference.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MENFORCER-271) Dependency convergence rule is very slow in larger projects
[
https://issues.apache.org/jira/browse/MENFORCER-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MENFORCER-271:
---
Attachment: visualvm.PNG
> Dependency convergence rule is very slow in larger projects
> ---
>
> Key: MENFORCER-271
> URL: https://issues.apache.org/jira/browse/MENFORCER-271
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: C:\Program Files\apache-maven-3.3.9
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.8.0_102\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Falko Modler
> Attachments: visualvm.PNG, visualvm_settings.PNG
>
>
> I noticed that DependencyConvergence can take up to 10 seconds or even more
> in modules with almost 300 direct and transitive dependencies (reported by
> {{dependency:tree}}).
> These modules are part of a JEE project based on JBoss EAP 6.4 which imports
> a couple of EAP BOMs. Unfortunately I am not allowed to share this project.
> I profiled the rule via VisualVM and these are the top 5 hotspots:
> !visualvm.PNG!
> The number of {{parseVersion}} calls seems excessive.
> See attached {{visualvm_settings.xml}} for reference.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MENFORCER-271) Dependency convergence rule is very slow in larger projects
Falko Modler created MENFORCER-271:
--
Summary: Dependency convergence rule is very slow in larger
projects
Key: MENFORCER-271
URL: https://issues.apache.org/jira/browse/MENFORCER-271
Project: Maven Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 1.4.1
Environment: Apache Maven 3.3.9
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
Maven home: C:\Program Files\apache-maven-3.3.9
Java version: 1.8.0_102, vendor: Oracle Corporation
Java home: C:\Develop\jdk1.8.0_102\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
Reporter: Falko Modler
Attachments: visualvm.PNG, visualvm_settings.PNG
I noticed that DependencyConvergence can take up to 10 seconds or even more in
modules with almost 300 direct and transitive dependencies (reported by
{{dependency:tree}}).
These modules are part of a JEE project based on JBoss EAP 6.4 which imports a
couple of EAP BOMs. Unfortunately I am not allowed to share this project.
I profiled the rule via VisualVM and these are the top 5 hotspots:
!visualvm.PNG!
The number of {{parseVersion}} calls seems excessive.
See attached {{visualvm_settings.xml}} for reference.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MENFORCER-271) Dependency convergence rule is very slow in larger projects
[
https://issues.apache.org/jira/browse/MENFORCER-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MENFORCER-271:
---
Attachment: visualvm_settings.PNG
> Dependency convergence rule is very slow in larger projects
> ---
>
> Key: MENFORCER-271
> URL: https://issues.apache.org/jira/browse/MENFORCER-271
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: C:\Program Files\apache-maven-3.3.9
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.8.0_102\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Falko Modler
> Attachments: visualvm.PNG, visualvm_settings.PNG
>
>
> I noticed that DependencyConvergence can take up to 10 seconds or even more
> in modules with almost 300 direct and transitive dependencies (reported by
> {{dependency:tree}}).
> These modules are part of a JEE project based on JBoss EAP 6.4 which imports
> a couple of EAP BOMs. Unfortunately I am not allowed to share this project.
> I profiled the rule via VisualVM and these are the top 5 hotspots:
> !visualvm.PNG!
> The number of {{parseVersion}} calls seems excessive.
> See attached {{visualvm_settings.xml}} for reference.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MENFORCER-270) option to forbid plugin snapshot versions only when releasing
[ https://issues.apache.org/jira/browse/MENFORCER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gruust updated MENFORCER-270: - Summary: option to forbid plugin snapshot versions only when releasing (was: option to allow plugin snapshot versions when not releasing) > option to forbid plugin snapshot versions only when releasing > - > > Key: MENFORCER-270 > URL: https://issues.apache.org/jira/browse/MENFORCER-270 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 1.4.1 >Reporter: Gruust >Priority: Minor > > Basically, it would be nice if plugin versions would be treated similar to > regular dependencies, ie. have a standard rule that only complains about > snapshot plugin versions when trying to release the project. That's > especially helpful when having maven plugin sub-modules as part of a larger > multi-module project. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MENFORCER-270) option to allow plugin snapshot versions when not releasing
Gruust created MENFORCER-270: Summary: option to allow plugin snapshot versions when not releasing Key: MENFORCER-270 URL: https://issues.apache.org/jira/browse/MENFORCER-270 Project: Maven Enforcer Plugin Issue Type: Improvement Components: Standard Rules Affects Versions: 1.4.1 Reporter: Gruust Priority: Minor Basically, it would be nice if plugin versions would be treated similar to regular dependencies, ie. have a standard rule that only complains about snapshot plugin versions when trying to release the project. That's especially helpful when having maven plugin sub-modules as part of a larger multi-module project. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
