[jira] [Commented] (MDEPLOY-286) Wrong documentation for format of altDeploymentRepository
[
https://issues.apache.org/jira/browse/MDEPLOY-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405049#comment-17405049
]
Roland Illig commented on MDEPLOY-286:
--
Do you have plans for releasing 3.0.0-M2, to avoid duplicate bug reports like
this?
> Wrong documentation for format of altDeploymentRepository
> -
>
> Key: MDEPLOY-286
> URL: https://issues.apache.org/jira/browse/MDEPLOY-286
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Roland Illig
>Priority: Minor
>
> [https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html] says:
> > Format: id::layout::url
> As of version 3.0.0-M1, this is wrong. The format is now simply `id::url`.
> The old format is no longer accepted.
> While here, the documentation for {{altReleaseDeploymentRepository}} and
> {{altSnapshotDeploymentRepository}}. could be extended to contain the same
> information as the {{altDeploymentRepository}}. The current documentation is
> not completely clear on whether the syntax of these 3 properties follows the
> same rules.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MDEPLOY-286) Wrong documentation for format of altDeploymentRepository
Roland Illig created MDEPLOY-286:
Summary: Wrong documentation for format of altDeploymentRepository
Key: MDEPLOY-286
URL: https://issues.apache.org/jira/browse/MDEPLOY-286
Project: Maven Deploy Plugin
Issue Type: Bug
Affects Versions: 3.0.0-M1
Reporter: Roland Illig
[https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html] says:
> Format: id::layout::url
As of version 3.0.0-M1, this is wrong. The format is now simply `id::url`. The
old format is no longer accepted.
While here, the documentation for {{altReleaseDeploymentRepository}} and
{{altSnapshotDeploymentRepository}}. could be extended to contain the same
information as the {{altDeploymentRepository}}. The current documentation is
not completely clear on whether the syntax of these 3 properties follows the
same rules.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MRELEASE-1069) typo: it's
Roland Illig created MRELEASE-1069: -- Summary: typo: it's Key: MRELEASE-1069 URL: https://issues.apache.org/jira/browse/MRELEASE-1069 Project: Maven Release Plugin Issue Type: Bug Components: documentation Affects Versions: 3.0.0-M4 Reporter: Roland Illig [http://maven.apache.org/maven-release/maven-release-plugin/usage.html] says: > is deployed with it's documentation It should rather be: > is deployed with its documentation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MENFORCER-335) Documentation suggests unreliable practice for dependency convergence
[ https://issues.apache.org/jira/browse/MENFORCER-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roland Illig updated MENFORCER-335: --- Description: The [documentation for Dependency Convergence|https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html] describes how to suppress an error reported by the check. This description leads to unreliable project configurations. It may or may not be intentional that the documentation merely states "And this will succeed" without explicitly saying that doing this is good or bad practice. In the example from the documentation, using an exclusion element works for the very moment, but as soon as the dependency slf4j-jdk14 is no longer needed, the project will break since slf4j-api is still required by slf4j-nop, but not included anymore. A more reliable and sustainable solution would be to have declarations like the following: * If one dependency chain ends in org.slf4j:slf4j-api:1.6.1 and another ends in org.slf4j:slf4j-api:1.6.0, use version 1.6.1. The general pattern is: * If one dependency chain ends in $coordinate1 and another ends in $coordinate2, use version $version. Using this pattern instead of globally saying "don't use version 1.6.0" would not break the above scenario where slf4j-jdk14 is no longer needed. Even better, since during dependency resolution this particular conflict does not occur anymore, this rule can be flagged as being no longer necessary. It should be possible to specify not only the last coordinate of a dependency chain but any elements, as in the following example: * If one dependency chain ends in org.slf4j:slf4j-jdk14:1.6.1, org.slf4j:slf4j-api:1.6.1 and another ends in org.slf4j:slf4j-nop:1.6.0, org.slf4j:slf4j-api:1.6.0, use version 1.6.1. As it is now, the dependency convergence test encourages Maven users to specify overly general and therefore wrong exclusion rules. This should be avoided. was: The [documentation for Dependency Convergence|https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html] describes how to suppress an error reported by the check. This description leads to unreliable project configurations. In the example from the documentation, using an exclusion element works for the very moment, but as soon as the dependency slf4j-jdk14 is no longer needed, the project will break since slf4j-api is still required by slf4j-nop, but not included anymore. A more reliable and sustainable solution would be to have declarations like the following: * If one dependency chain ends in org.slf4j:slf4j-api:1.6.1 and another ends in org.slf4j:slf4j-api:1.6.0, use version 1.6.1. The general pattern is: * If one dependency chain ends in $coordinate1 and another ends in $coordinate2, use version $version. Using this pattern instead of globally saying "don't use version 1.6.0" would not break the above scenario where slf4j-jdk14 is no longer needed. Even better, since during dependency resolution this particular conflict does not occur anymore, this rule can be flagged as being no longer necessary. It should be possible to specify not only the last coordinate of a dependency chain but any elements, as in the following example: * If one dependency chain ends in org.slf4j:slf4j-jdk14:1.6.1, org.slf4j:slf4j-api:1.6.1 and another ends in org.slf4j:slf4j-nop:1.6.0, org.slf4j:slf4j-api:1.6.0, use version 1.6.1. As it is now, the dependency convergence test encourages Maven users to specify overly general and therefore wrong exclusion rules. This should be avoided. > Documentation suggests unreliable practice for dependency convergence > - > > Key: MENFORCER-335 > URL: https://issues.apache.org/jira/browse/MENFORCER-335 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Documentation >Reporter: Roland Illig >Priority: Major > > The [documentation for Dependency > Convergence|https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html] > describes how to suppress an error reported by the check. This description > leads to unreliable project configurations. It may or may not be intentional > that the documentation merely states "And this will succeed" without > explicitly saying that doing this is good or bad practice. > In the example from the documentation, using an exclusion element works for > the very moment, but as soon as the dependency slf4j-jdk14 is no longer > needed, the project will break since slf4j-api is still required by > slf4j-nop, but not included anymore. > A more reliable and sustainable solution would be to have declarations like > the following: > * If one dependency chain ends in org.slf4j:slf4j-api:1.6.1 and another ends > in org.slf4j:slf4j-api:1.6.0, use version
[jira] [Updated] (MENFORCER-335) Documentation suggests unreliable practice for dependency convergence
[ https://issues.apache.org/jira/browse/MENFORCER-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roland Illig updated MENFORCER-335: --- Affects Version/s: 3.0.0-M2 > Documentation suggests unreliable practice for dependency convergence > - > > Key: MENFORCER-335 > URL: https://issues.apache.org/jira/browse/MENFORCER-335 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Documentation >Affects Versions: 3.0.0-M2 >Reporter: Roland Illig >Priority: Major > > The [documentation for Dependency > Convergence|https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html] > describes how to suppress an error reported by the check. This description > leads to unreliable project configurations. It may or may not be intentional > that the documentation merely states "And this will succeed" without > explicitly saying that doing this is good or bad practice. > In the example from the documentation, using an exclusion element works for > the very moment, but as soon as the dependency slf4j-jdk14 is no longer > needed, the project will break since slf4j-api is still required by > slf4j-nop, but not included anymore. > A more reliable and sustainable solution would be to have declarations like > the following: > * If one dependency chain ends in org.slf4j:slf4j-api:1.6.1 and another ends > in org.slf4j:slf4j-api:1.6.0, use version 1.6.1. > The general pattern is: > * If one dependency chain ends in $coordinate1 and another ends in > $coordinate2, use version $version. > Using this pattern instead of globally saying "don't use version 1.6.0" would > not break the above scenario where slf4j-jdk14 is no longer needed. Even > better, since during dependency resolution this particular conflict does not > occur anymore, this rule can be flagged as being no longer necessary. > It should be possible to specify not only the last coordinate of a dependency > chain but any elements, as in the following example: > * If one dependency chain ends in org.slf4j:slf4j-jdk14:1.6.1, > org.slf4j:slf4j-api:1.6.1 and another ends in org.slf4j:slf4j-nop:1.6.0, > org.slf4j:slf4j-api:1.6.0, use version 1.6.1. > As it is now, the dependency convergence test encourages Maven users to > specify overly general and therefore wrong exclusion rules. This should be > avoided. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (MDEPLOY-222) Issue Tracking in pom.xml points to outdated Codehaus site
[ https://issues.apache.org/jira/browse/MDEPLOY-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324142#comment-16324142 ] Roland Illig commented on MDEPLOY-222: -- To everyone possibly reporting a duplicate of this issue: The last release of this plugin was in 2014, so it may take some time until this change to the web site is visible. Until then, good luck submitting new issues for this plugin. (In other words, [~khmarbaise], could you perhaps trigger a release of this plugin, even if just for providing up-to-date documentation?) > Issue Tracking in pom.xml points to outdated Codehaus site > -- > > Key: MDEPLOY-222 > URL: https://issues.apache.org/jira/browse/MDEPLOY-222 > Project: Maven Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.8.2 >Reporter: Roland Illig >Assignee: Hervé Boutemy >Priority: Minor > Fix For: 3.0.0 > > > https://maven.apache.org/plugins/maven-deploy-plugin/issue-tracking.html > points to http://jira.codehaus.org/browse/MDEPLOY. This should be updated to > https://issues.apache.org/jira/browse/MDEPLOY. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MRESOLVER-25) Resume support is broken under high concurrency
[
https://issues.apache.org/jira/browse/MRESOLVER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16028146#comment-16028146
]
Roland Illig commented on MRESOLVER-25:
---
Yes, exactly that.
> Resume support is broken under high concurrency
> ---
>
> Key: MRESOLVER-25
> URL: https://issues.apache.org/jira/browse/MRESOLVER-25
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: Maven Artifact Resolver 1.0.3
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip,
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local
> Maven repository without taking into account that other threads or processes
> might do the same at the same time.
> To reproduce:
> 1. unpack the attached project
> 2. {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be
> found". This is wrong, since the dependency _can_ be found, it's just not
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MRESOLVER-25) Resume support is broken under high concurrency
[
https://issues.apache.org/jira/browse/MRESOLVER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16028108#comment-16028108
]
Roland Illig commented on MRESOLVER-25:
---
Yes, the workaround works for me. Thank you.
The files were downloaded correctly and I got a {{BUILD SUCCESS}}, I just got
the following exception about 7 times, for several of the involved artifacts:
{noformat}
[WARNING] Failed to write tracking file
C:\Users\rillig\.m2\repository\org\webjars\bower\datatables.net-buttons\1.2.4\datatables.net-buttons-1.2.4.pom.lastUpdated
java.io.FileNotFoundException:
C:\Users\rillig\.m2\repository\org\webjars\bower\datatables.net-buttons\1.2.4\datatables.net-buttons-1.2.4.pom.lastUpdated
(Zugriff verweigert)
at java.io.RandomAccessFile.open0(Native Method)
at java.io.RandomAccessFile.open(RandomAccessFile.java:316)
at java.io.RandomAccessFile.(RandomAccessFile.java:243)
at
org.eclipse.aether.internal.impl.TrackingFileManager.update(TrackingFileManager.java:96)
at
org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write(DefaultUpdateCheckManager.java:602)
at
org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact(DefaultUpdateCheckManager.java:538)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads(DefaultArtifactResolver.java:631)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:550)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:436)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:262)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:239)
{noformat}
> Resume support is broken under high concurrency
> ---
>
> Key: MRESOLVER-25
> URL: https://issues.apache.org/jira/browse/MRESOLVER-25
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: Maven Artifact Resolver 1.0.3
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip,
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local
> Maven repository without taking into account that other threads or processes
> might do the same at the same time.
> To reproduce:
> 1. unpack the attached project
> 2. {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be
> found". This is wrong, since the dependency _can_ be found, it's just not
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Issue Comment Deleted] (MRESOLVER-25) Resume support is broken under high concurrency
[
https://issues.apache.org/jira/browse/MRESOLVER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roland Illig updated MRESOLVER-25:
--
Comment: was deleted
(was: Hello [~michael-o], did you find time to look into this issue?)
> Resume support is broken under high concurrency
> ---
>
> Key: MRESOLVER-25
> URL: https://issues.apache.org/jira/browse/MRESOLVER-25
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: Maven Artifact Resolver 1.0.3
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip,
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local
> Maven repository without taking into account that other threads or processes
> might do the same at the same time.
> To reproduce:
> 1. unpack the attached project
> 2. {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be
> found". This is wrong, since the dependency _can_ be found, it's just not
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Issue Comment Deleted] (MRESOLVER-25) Resume support is broken under high concurrency
[
https://issues.apache.org/jira/browse/MRESOLVER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roland Illig updated MRESOLVER-25:
--
Comment: was deleted
(was: Hello [~michael-o], did you find time to look into this issue?)
> Resume support is broken under high concurrency
> ---
>
> Key: MRESOLVER-25
> URL: https://issues.apache.org/jira/browse/MRESOLVER-25
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: Maven Artifact Resolver 1.0.3
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip,
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local
> Maven repository without taking into account that other threads or processes
> might do the same at the same time.
> To reproduce:
> 1. unpack the attached project
> 2. {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be
> found". This is wrong, since the dependency _can_ be found, it's just not
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Issue Comment Deleted] (MRESOLVER-25) Resume support is broken under high concurrency
[
https://issues.apache.org/jira/browse/MRESOLVER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roland Illig updated MRESOLVER-25:
--
Comment: was deleted
(was: Hello [~michael-o]. Is there any progress on this issue?)
> Resume support is broken under high concurrency
> ---
>
> Key: MRESOLVER-25
> URL: https://issues.apache.org/jira/browse/MRESOLVER-25
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: Maven Artifact Resolver 1.0.3
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip,
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local
> Maven repository without taking into account that other threads or processes
> might do the same at the same time.
> To reproduce:
> 1. unpack the attached project
> 2. {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be
> found". This is wrong, since the dependency _can_ be found, it's just not
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6156) Resolving dependencies is not thread-safe
[
https://issues.apache.org/jira/browse/MNG-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16023220#comment-16023220
]
Roland Illig commented on MNG-6156:
---
No, I don't want to give it a try since I'm not familiar with Maven development
procedures. When you say it's a Maven Resolver issue, does that mean I need to
file a ticket for a different project?
> Resolving dependencies is not thread-safe
> -
>
> Key: MNG-6156
> URL: https://issues.apache.org/jira/browse/MNG-6156
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.9
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip,
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local
> Maven repository without taking into account that other threads or processes
> might do the same at the same time.
> To reproduce:
> 1. unpack the attached project
> 2. {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be
> found". This is wrong, since the dependency _can_ be found, it's just not
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}
--
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=16006178#comment-16006178
]
Roland Illig commented on MDEPLOY-221:
--
Regarding your questions:
* Is this the whole output for uploading artifacts?
** Unfortunately, I don't have access to this particular build log anymore (as
old logs are automatically removed). What I remember is that this is from a
multi-module project, and there were several lines saying something like
"deploy will be run at the end".
* Have you checked your build output if you have duplicated
maven-install-plugin calls?
** Since this is a multi-module build, there is one call of
{{maven-install-plugin}} per module, as I expect it.
* I saw an artifact obfuscated ? How does the log output look like there?
** Nothing special. It's a jar file, it's built somehow and then uploaded. Why
could this influence anything?
* Are you using parallelization? (mvn -T ...)
** Yes, we are using {{mvn -T 8}}.
* Which version of Nexus do you use?
** We are using {{Nexus Repository Manager OSS 2.13.0-01}}. I would expect this
to be irrelevant though, since I assume that the {{maven-metadata.xml}} is just
uploaded as-is, especially since the timestamp is the same as the other
uploaded files.
> 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:
>
[jira] [Created] (MDEPLOY-222) Issue Tracking in pom.xml points to outdated Codehaus site
Roland Illig created MDEPLOY-222: Summary: Issue Tracking in pom.xml points to outdated Codehaus site Key: MDEPLOY-222 URL: https://issues.apache.org/jira/browse/MDEPLOY-222 Project: Maven Deploy Plugin Issue Type: Bug Affects Versions: 2.8.2 Reporter: Roland Illig https://maven.apache.org/plugins/maven-deploy-plugin/issue-tracking.html points to http://jira.codehaus.org/browse/MDEPLOY. This should be updated to https://issues.apache.org/jira/browse/MDEPLOY. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MDEPLOY-221) deploy generates wrong timestamps in maven-metadata.xml
Roland Illig created MDEPLOY-221:
Summary: 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:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
(1.2 kB at 37 kB/s)
[INFO] Uploading:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-test-sources.jar
[INFO] Uploaded:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-test-sources.jar
(10 kB at 286 kB/s)
[INFO] Downloading:
http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
[INFO] Downloaded:
[jira] [Commented] (MNG-6156) Resolving dependencies is not thread-safe
[
https://issues.apache.org/jira/browse/MNG-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16004348#comment-16004348
]
Roland Illig commented on MNG-6156:
---
Hello [~michael-o], did you find time to look into this issue?
> Resolving dependencies is not thread-safe
> -
>
> Key: MNG-6156
> URL: https://issues.apache.org/jira/browse/MNG-6156
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.9
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip,
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local
> Maven repository without taking into account that other threads or processes
> might do the same at the same time.
> To reproduce:
> 1. unpack the attached project
> 2. {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be
> found". This is wrong, since the dependency _can_ be found, it's just not
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6156) Resolving dependencies is not thread-safe
[
https://issues.apache.org/jira/browse/MNG-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15958498#comment-15958498
]
Roland Illig commented on MNG-6156:
---
Hello [~michael-o], did you find time to look into this issue?
> Resolving dependencies is not thread-safe
> -
>
> Key: MNG-6156
> URL: https://issues.apache.org/jira/browse/MNG-6156
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.9
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip,
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local
> Maven repository without taking into account that other threads or processes
> might do the same at the same time.
> To reproduce:
> 1. unpack the attached project
> 2. {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be
> found". This is wrong, since the dependency _can_ be found, it's just not
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6156) Resolving dependencies is not thread-safe
[
https://issues.apache.org/jira/browse/MNG-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15879015#comment-15879015
]
Roland Illig commented on MNG-6156:
---
Hello [~michael-o], did you find time to look into this issue?
> Resolving dependencies is not thread-safe
> -
>
> Key: MNG-6156
> URL: https://issues.apache.org/jira/browse/MNG-6156
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.9
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip,
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local
> Maven repository without taking into account that other threads or processes
> might do the same at the same time.
> To reproduce:
> 1. unpack the attached project
> 2. {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be
> found". This is wrong, since the dependency _can_ be found, it's just not
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6156) Resolving dependencies is not thread-safe
[
https://issues.apache.org/jira/browse/MNG-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15849878#comment-15849878
]
Roland Illig commented on MNG-6156:
---
Hello [~michael-o]. Is there any progress on this issue?
> Resolving dependencies is not thread-safe
> -
>
> Key: MNG-6156
> URL: https://issues.apache.org/jira/browse/MNG-6156
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.9
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip,
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local
> Maven repository without taking into account that other threads or processes
> might do the same at the same time.
> To reproduce:
> 1. unpack the attached project
> 2. {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be
> found". This is wrong, since the dependency _can_ be found, it's just not
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6156) Resolving dependencies is not thread-safe
[
https://issues.apache.org/jira/browse/MNG-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roland Illig updated MNG-6156:
--
Attachment: dependency-list-x.zip
> Resolving dependencies is not thread-safe
> -
>
> Key: MNG-6156
> URL: https://issues.apache.org/jira/browse/MNG-6156
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.9
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip,
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local
> Maven repository without taking into account that other threads or processes
> might do the same at the same time.
> To reproduce:
> 1. unpack the attached project
> 2. {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be
> found". This is wrong, since the dependency _can_ be found, it's just not
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-6156) Resolving dependencies is not thread-safe
[
https://issues.apache.org/jira/browse/MNG-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15823849#comment-15823849
]
Roland Illig commented on MNG-6156:
---
Thanks for the reply. Your instructions were a bit vague, so here is what I
tried:
* {{svn checkout
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-dependency-plugin}}
* {{(cd maven-dependency-plugin && mvn install)}}
* {{(cd MNG-6156 && mvn
org.apache.maven.plugins:maven-dependency-plugin:3.0.1-SNAPSHOT:list -T100 -U
-B}} (reliably fails)
* {{(cd MNG-6156 && mvn
org.apache.maven.plugins:maven-dependency-plugin:3.0.0:list -T100 -U -B}}
(reliably fails)
Of which command do you want the _log file with debug logging enabled_? What
kind of debugging log, just {{-X}}?
> Resolving dependencies is not thread-safe
> -
>
> Key: MNG-6156
> URL: https://issues.apache.org/jira/browse/MNG-6156
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.9
>Reporter: Roland Illig
> Attachments: dependency-list.txt, wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local
> Maven repository without taking into account that other threads or processes
> might do the same at the same time.
> To reproduce:
> 1. unpack the attached project
> 2. {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be
> found". This is wrong, since the dependency _can_ be found, it's just not
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-6156) Resolving dependencies is not thread-safe
Roland Illig created MNG-6156:
-
Summary: Resolving dependencies is not thread-safe
Key: MNG-6156
URL: https://issues.apache.org/jira/browse/MNG-6156
Project: Maven
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.3.9
Reporter: Roland Illig
Attachments: dependency-list.txt, wagon-not-threadsafe.zip
When building a multi-module project in parallel, Maven updates the local Maven
repository without taking into account that other threads or processes might do
the same at the same time.
To reproduce:
1. unpack the attached project
2. {{mvn dependency:list -U -B -T100}}
See the attached {{dependency-list.txt}} for an example output.
First thing to notice is that the dependency is downloaded 100 times. This is
unexpected, since the Reactor should coordinate all the modules.
Second thing to notice is that the build fails, since a dependency "cannot be
found". This is wrong, since the dependency _can_ be found, it's just not
processed properly.
I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since the
typical error messages are:
* {{"Downloaded file does not exist: "}}
* {{"Error copying temporary file to the final destination: "}}
* {{"*** CHECKSUM FAILED - RETRYING"}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
