[jira] [Commented] (MNG-6233) maven-resolver-provider mixes JRS 330 and Plexus annotations
[ https://issues.apache.org/jira/browse/MNG-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16023784#comment-16023784 ] Michael Osipov commented on MNG-6233: - bq. I am not sure what you mean by "merged Jason Dillon's changed with this PR". The change I propose fully converts maven-resolver-provider to jsr330 annotations, which means only jsr330 codepaths are used after the change and our existing ITs prove everything works. In other words, it is not possible to implement jsr330 conversion (i.e. this change) without fixing Jason's problem too, so this change really supersedes PR 116. OK, that's what I wanted to know. Though, the commit message does not has the same title as the JIRA issue and you should have simply added "This closes #116" too. The change itself is perfectly fine. > maven-resolver-provider mixes JRS 330 and Plexus annotations > > > Key: MNG-6233 > URL: https://issues.apache.org/jira/browse/MNG-6233 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9, 3.5.0 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.1 > > > Mixed annotations confuse guice/sisu and result in hard to troubleshoot and > impossible to workaround problems in applications that embed Maven core > runtime, like m2e and gshell. > I believe plugins annotations where left in the code by mistake so the plan > is to update the code to use jsr330 exclusively and completely remove plexus > annotations. This change is fully transparent to the users (and we've been > using it internally for couple of months now). > See also https://github.com/apache/maven/pull/116 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-6233) maven-resolver-provider mixes JRS 330 and Plexus annotations
[ https://issues.apache.org/jira/browse/MNG-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6233: Summary: maven-resolver-provider mixes JRS 330 and Plexus annotations (was: maven-resolver-provider mixes jsr330 and plexus annotations) > maven-resolver-provider mixes JRS 330 and Plexus annotations > > > Key: MNG-6233 > URL: https://issues.apache.org/jira/browse/MNG-6233 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9, 3.5.0 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.1 > > > Mixed annotations confuse guice/sisu and result in hard to troubleshoot and > impossible to workaround problems in applications that embed Maven core > runtime, like m2e and gshell. > I believe plugins annotations where left in the code by mistake so the plan > is to update the code to use jsr330 exclusively and completely remove plexus > annotations. This change is fully transparent to the users (and we've been > using it internally for couple of months now). > See also https://github.com/apache/maven/pull/116 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6233) maven-resolver-provider mixes jsr330 and plexus annotations
[ https://issues.apache.org/jira/browse/MNG-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16023724#comment-16023724 ] Igor Fedorenko commented on MNG-6233: - My apologies, I assumed I addressed all concerned about my change here already and didn't ask on the mailing list. Let me do that now and I'll revert my change if I don't get +1s (or get -1s) within 72 hours. I am not sure what you mean by "merged Jason Dillon's changed with this PR". The change I propose fully converts maven-resolver-provider to jsr330 annotations, which means only jsr330 codepaths are used after the change and our existing ITs prove everything works. In other words, it is not possible to implement jsr330 conversion (i.e. this change) without fixing Jason's problem too, so this change really supersedes PR 116. > maven-resolver-provider mixes jsr330 and plexus annotations > --- > > Key: MNG-6233 > URL: https://issues.apache.org/jira/browse/MNG-6233 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9, 3.5.0 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.1 > > > Mixed annotations confuse guice/sisu and result in hard to troubleshoot and > impossible to workaround problems in applications that embed Maven core > runtime, like m2e and gshell. > I believe plugins annotations where left in the code by mistake so the plan > is to update the code to use jsr330 exclusively and completely remove plexus > annotations. This change is fully transparent to the users (and we've been > using it internally for couple of months now). > See also https://github.com/apache/maven/pull/116 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6223) mvn -f outputs invalid error when specifying POM directory
[
https://issues.apache.org/jira/browse/MNG-6223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16023646#comment-16023646
]
Hervé Boutemy commented on MNG-6223:
thank you for the reference: now we did a core IT, we won't have regression on
this in the future
> mvn -f outputs invalid error when specifying POM directory
> --
>
> Key: MNG-6223
> URL: https://issues.apache.org/jira/browse/MNG-6223
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0-alpha-1, 3.5.0
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T15:39:06-04:00)
> Maven home: /Users/cgould/dev/tools/apache-maven-3.5.0
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
>Reporter: Charles Gould
>Assignee: Hervé Boutemy
>Priority: Minor
> Fix For: 3.5.1
>
> Attachments: alternate-pom.zip
>
>
> Basic multi-module project: common, client, and server modules.
>
> {noformat}
> $ mvn -f client package
> POM file client specified with the -f/--file command line argument does not
> exist
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building alternate-pom-client 1.0
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> alternate-pom-client ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /Users/cgould/dev/personal/alternate-pom/client/src/main/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
> alternate-pom-client ---
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
> alternate-pom-client ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /Users/cgould/dev/personal/alternate-pom/client/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @
> alternate-pom-client ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @
> alternate-pom-client ---
> [INFO] No tests to run.
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ alternate-pom-client ---
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.764 s
> [INFO] Finished at: 2017-04-29T14:03:22-04:00
> [INFO] Final Memory: 11M/309M
> [INFO]
>
> {noformat}
> There is an error message, but the client module proceeds to build
> nonetheless.
> I don't see the error message when I run:
> {noformat}
> $ mvn -f client/pom.xml package
> {noformat}
> I've verified it doesn't happen on 3.3.9, but it does happen on 3.5.0 and
> 3.5.0-alpha-1.
> Sample project attached.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6084) Support JSR 250 annotations
[ https://issues.apache.org/jira/browse/MNG-6084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6084: Fix Version/s: (was: needing-scrub-3.4.0-fallout) 3.5.1-candidate > Support JSR 250 annotations > --- > > Key: MNG-6084 > URL: https://issues.apache.org/jira/browse/MNG-6084 > Project: Maven > Issue Type: New Feature > Components: core >Affects Versions: 3.3.9 >Reporter: Dan Tran >Assignee: Dan Tran > Fix For: 3.5.1-candidate > > > JSR330 ( @Named, @Singeton, etc) currently supported for plugin development. > Would like to see JSR250 as well(@PostConstruct, etc) > Detail discussion is at > http://maven.40175.n5.nabble.com/Maven-Plugin-and-JSR330-td5879508.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (MNG-6233) maven-resolver-provider mixes jsr330 and plexus annotations
[ https://issues.apache.org/jira/browse/MNG-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16023586#comment-16023586 ] Michael Osipov edited comment on MNG-6233 at 5/24/17 8:06 PM: -- There are two problems now: 1. No one seconded this candidate. We agreed to have a seconder on the dev mailing list 2. You didn't read my comments on GitHub and merged [~jdillon]'s changed with this PR although this is not related. was (Author: michael-o): There are two problems now: 1. No one seconded this candidate. We agreed to have a seconder on the dev mailing list 2. You didn't read my comments on GitHub and merged [~jdillon]s changed with this PR although this is not related w/o an IT. > maven-resolver-provider mixes jsr330 and plexus annotations > --- > > Key: MNG-6233 > URL: https://issues.apache.org/jira/browse/MNG-6233 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9, 3.5.0 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.1 > > > Mixed annotations confuse guice/sisu and result in hard to troubleshoot and > impossible to workaround problems in applications that embed Maven core > runtime, like m2e and gshell. > I believe plugins annotations where left in the code by mistake so the plan > is to update the code to use jsr330 exclusively and completely remove plexus > annotations. This change is fully transparent to the users (and we've been > using it internally for couple of months now). > See also https://github.com/apache/maven/pull/116 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6233) maven-resolver-provider mixes jsr330 and plexus annotations
[ https://issues.apache.org/jira/browse/MNG-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16023586#comment-16023586 ] Michael Osipov commented on MNG-6233: - There are two problems now: 1. No one seconded this candidate. We agreed to have a seconder on the dev mailing list 2. You didn't read my comments on GitHub and merged [~jdillon]s changed with this PR although this is not related w/o an IT. > maven-resolver-provider mixes jsr330 and plexus annotations > --- > > Key: MNG-6233 > URL: https://issues.apache.org/jira/browse/MNG-6233 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9, 3.5.0 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.1 > > > Mixed annotations confuse guice/sisu and result in hard to troubleshoot and > impossible to workaround problems in applications that embed Maven core > runtime, like m2e and gshell. > I believe plugins annotations where left in the code by mistake so the plan > is to update the code to use jsr330 exclusively and completely remove plexus > annotations. This change is fully transparent to the users (and we've been > using it internally for couple of months now). > See also https://github.com/apache/maven/pull/116 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6233) maven-resolver-provider mixes jsr330 and plexus annotations
[ https://issues.apache.org/jira/browse/MNG-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16023565#comment-16023565 ] Hudson commented on MNG-6233: - SUCCESS: Integrated in Jenkins build maven-3.x #1653 (See [https://builds.apache.org/job/maven-3.x/1653/]) MNG-6233 don't mix plexus and jsr330 annotations in aether-provider (ifedorenko: [http://git-wip-us.apache.org/repos/asf/?p=maven.git=commit=66fc74d6296ea0a33f8a9712dc5ed5eb3affd529]) * (edit) maven-resolver-provider/pom.xml * (edit) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/VersionsMetadataGeneratorFactory.java * (edit) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java * (edit) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionResolver.java * (edit) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java * (edit) maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/SnapshotMetadataGeneratorFactory.java > maven-resolver-provider mixes jsr330 and plexus annotations > --- > > Key: MNG-6233 > URL: https://issues.apache.org/jira/browse/MNG-6233 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9, 3.5.0 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.1 > > > Mixed annotations confuse guice/sisu and result in hard to troubleshoot and > impossible to workaround problems in applications that embed Maven core > runtime, like m2e and gshell. > I believe plugins annotations where left in the code by mistake so the plan > is to update the code to use jsr330 exclusively and completely remove plexus > annotations. This change is fully transparent to the users (and we've been > using it internally for couple of months now). > See also https://github.com/apache/maven/pull/116 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MNG-6233) maven-resolver-provider mixes jsr330 and plexus annotations
[ https://issues.apache.org/jira/browse/MNG-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko resolved MNG-6233. - Resolution: Fixed Fix Version/s: (was: 3.5.1-candidate) 3.5.1 Submitted the fix as https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=66fc74d6296ea0a33f8a9712dc5ed5eb3affd529 > maven-resolver-provider mixes jsr330 and plexus annotations > --- > > Key: MNG-6233 > URL: https://issues.apache.org/jira/browse/MNG-6233 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9, 3.5.0 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.1 > > > Mixed annotations confuse guice/sisu and result in hard to troubleshoot and > impossible to workaround problems in applications that embed Maven core > runtime, like m2e and gshell. > I believe plugins annotations where left in the code by mistake so the plan > is to update the code to use jsr330 exclusively and completely remove plexus > annotations. This change is fully transparent to the users (and we've been > using it internally for couple of months now). > See also https://github.com/apache/maven/pull/116 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6223) mvn -f outputs invalid error when specifying POM directory
[
https://issues.apache.org/jira/browse/MNG-6223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16023504#comment-16023504
]
Jesse Glick commented on MNG-6223:
--
Was a regression of MNG-5338.
> mvn -f outputs invalid error when specifying POM directory
> --
>
> Key: MNG-6223
> URL: https://issues.apache.org/jira/browse/MNG-6223
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0-alpha-1, 3.5.0
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T15:39:06-04:00)
> Maven home: /Users/cgould/dev/tools/apache-maven-3.5.0
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
>Reporter: Charles Gould
>Assignee: Hervé Boutemy
>Priority: Minor
> Fix For: 3.5.1
>
> Attachments: alternate-pom.zip
>
>
> Basic multi-module project: common, client, and server modules.
>
> {noformat}
> $ mvn -f client package
> POM file client specified with the -f/--file command line argument does not
> exist
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building alternate-pom-client 1.0
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> alternate-pom-client ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /Users/cgould/dev/personal/alternate-pom/client/src/main/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
> alternate-pom-client ---
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
> alternate-pom-client ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /Users/cgould/dev/personal/alternate-pom/client/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @
> alternate-pom-client ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @
> alternate-pom-client ---
> [INFO] No tests to run.
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ alternate-pom-client ---
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.764 s
> [INFO] Finished at: 2017-04-29T14:03:22-04:00
> [INFO] Final Memory: 11M/309M
> [INFO]
>
> {noformat}
> There is an error message, but the client module proceeds to build
> nonetheless.
> I don't see the error message when I run:
> {noformat}
> $ mvn -f client/pom.xml package
> {noformat}
> I've verified it doesn't happen on 3.3.9, but it does happen on 3.5.0 and
> 3.5.0-alpha-1.
> Sample project attached.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6084) Support JSR 250 annotations
[ https://issues.apache.org/jira/browse/MNG-6084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6084: Summary: Support JSR 250 annotations (was: Support JSR250 annotations) > Support JSR 250 annotations > --- > > Key: MNG-6084 > URL: https://issues.apache.org/jira/browse/MNG-6084 > Project: Maven > Issue Type: New Feature > Components: core >Affects Versions: 3.3.9 >Reporter: Dan Tran >Assignee: Dan Tran > Fix For: needing-scrub-3.4.0-fallout > > > JSR330 ( @Named, @Singeton, etc) currently supported for plugin development. > Would like to see JSR250 as well(@PostConstruct, etc) > Detail discussion is at > http://maven.40175.n5.nabble.com/Maven-Plugin-and-JSR330-td5879508.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6233) maven-resolver-provider mixes jsr330 and plexus annotations
[ https://issues.apache.org/jira/browse/MNG-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16023408#comment-16023408 ] ASF GitHub Bot commented on MNG-6233: - Github user jdillon commented on the issue: https://github.com/apache/maven/pull/116 Igor already created https://issues.apache.org/jira/browse/MNG-6233 but if you really need another issue I can file one just to fix this specific problem. Seems a bit odd though that you want an IT to apply a clear coding mistake due to the ctor parameter being ignored and not setting the component causing NPE when used. :-( > maven-resolver-provider mixes jsr330 and plexus annotations > --- > > Key: MNG-6233 > URL: https://issues.apache.org/jira/browse/MNG-6233 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9, 3.5.0 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.1-candidate > > > Mixed annotations confuse guice/sisu and result in hard to troubleshoot and > impossible to workaround problems in applications that embed Maven core > runtime, like m2e and gshell. > I believe plugins annotations where left in the code by mistake so the plan > is to update the code to use jsr330 exclusively and completely remove plexus > annotations. This change is fully transparent to the users (and we've been > using it internally for couple of months now). > See also https://github.com/apache/maven/pull/116 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (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
]
Michael Osipov updated MRESOLVER-25:
Summary: Resume support is broken under high concurrency (was: Resolving
dependencies is not thread-safe)
> 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
]
Michael Osipov updated MRESOLVER-25:
Comment: was deleted
(was: Vielen Dank für Ihre Email.
Ich bin am 29.05.2017 wieder im Haus.
Ihre Email wird nicht weitergeleitet.
Mit freundlichen Grüßen
Thorsten Jacoby
)
> 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] [Moved] (MRESOLVER-25) Resolving dependencies is not thread-safe
[
https://issues.apache.org/jira/browse/MRESOLVER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov moved MNG-6156 to MRESOLVER-25:
--
Affects Version/s: (was: 3.3.9)
Maven Artifact Resolver 1.0.3
Component/s: (was: Artifacts and Repositories)
resolver
Workflow: jira (was: Default workflow, editable Closed status)
Key: MRESOLVER-25 (was: MNG-6156)
Project: Maven Resolver (was: Maven)
> Resolving dependencies is not thread-safe
> -
>
> 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=16023290#comment-16023290
]
Michael Osipov commented on MNG-6156:
-
I think I have a workaround for your issue: pass
{{-Daether.connector.resumeDownloads.=false}}.
> 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=16023249#comment-16023249
]
Michael Osipov commented on MNG-6156:
-
There is nothing to be familiar as long as you know Java and Git. There is no
need to file a new one. We can keep this with MNG as long as someone is capable
of fixing Maven Resolver. Then it can be moved easily within JIRA. I assume the
bug to be in this file:
https://github.com/apache/maven-resolver/blob/master/maven-resolver-connector-basic/src/main/java/org/eclipse/aether/connector/basic/PartialFile.java
> 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=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] [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
]
Thorsten Jacoby updated MNG-6156:
-
Vielen Dank für Ihre Email.
Ich bin am 29.05.2017 wieder im Haus.
Ihre Email wird nicht weitergeleitet.
Mit freundlichen Grüßen
Thorsten Jacoby
> 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=16023075#comment-16023075
]
Michael Osipov commented on MNG-6156:
-
I rechecked this and my previous statements holds true. It is a Maven Resolver
issue. Unfortunately, I am not really acquaint with the code to work out a
proper fix. Do you want to give it it a try? It is somewhere
{{TrackingFileManager}} and/or {{PartialFile}}.
> 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] [Comment Edited] (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=16023075#comment-16023075
]
Michael Osipov edited comment on MNG-6156 at 5/24/17 3:14 PM:
--
I rechecked this and my previous statement still holds true: it is a Maven
Resolver issue. Unfortunately, I am not really acquaint with the code to work
out a proper fix. Do you want to give it it a try? It is somewhere in
{{TrackingFileManager}} and/or {{PartialFile}}.
was (Author: michael-o):
I rechecked this and my previous statements holds true. It is a Maven Resolver
issue. Unfortunately, I am not really acquaint with the code to work out a
proper fix. Do you want to give it it a try? It is somewhere
{{TrackingFileManager}} and/or {{PartialFile}}.
> 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)
