[
https://issues.apache.org/jira/browse/MRESOLVER-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734260#comment-17734260
]
ASF GitHub Bot commented on MRESOLVER-373:
------------------------------------------
cstamas opened a new pull request, #302:
URL: https://github.com/apache/maven-resolver/pull/302
In change 4c5e9ea98f8815c6df8bf26baa9032c8d9cd5f2d we introduced code that
in some case tries illegal "lock upgrade", that due lack of MRESOLVER-220 went
unnoticed.
This change merely undoes the changes for DefaultArtifactResolver and
DefaultMetadataResolver (will as before, use exclusive SyncContext immediately,
not be "optimistic"), while change for DefaultDeploy is still correct.
---
https://issues.apache.org/jira/browse/MRESOLVER-373
> Partially undo MRESOLVER-346
> ----------------------------
>
> Key: MRESOLVER-373
> URL: https://issues.apache.org/jira/browse/MRESOLVER-373
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
> Reporter: Tamas Cservenak
> Priority: Major
> Fix For: 1.9.13
>
>
> The change done in MRESOLVER-346 in relation to DefaultArtifactResolver and
> DefaultMetadataResolver is wrong, and is actually complemented by
> MRESOLVER-349, so is really not needed. The change happened for
> DefaultDeployer is correct.
> In short, DefaultArtifactResolver within syncContext will invoke
> DefaultMetadataResolver that may case "lock upgrade" attempt that is NOT
> supported by named locks -> failure. Sadly, due push back on MRESOLVER-220
> this went unnoticed.
> Just undo the change and make two component as before, always use exclusive
> locks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
