[
https://issues.apache.org/jira/browse/MNG-7220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17402807#comment-17402807
]
Falko Modler commented on MNG-7220:
-----------------------------------
I think I got it!
The problem is how MavenProject is cloned for those forked lifecycles:
{{clone()}} simply copies {{threadLocalArtifactsHolder}} over to the clone and
so both instances share the same ThreadLocal, which is wrong and leads to
artifacts getting lost in the fork (in this specific case, different scenarios
might yield other stange results).
I succeeded in fixing this problem locally by swapping the copied
{{threadLocalArtifactsHolder}} with a new one and doing an explicit deep copy
of {{ArtifactsHolder}}.
I'll have to think about on how to clean this up. I'd rather prevent the TL
from being "copied" in the firstplace (instead of swapping it "manually").
> [REGRESSION] test-classpath incorrectly resolved
> -------------------------------------------------
>
> Key: MNG-7220
> URL: https://issues.apache.org/jira/browse/MNG-7220
> Project: Maven
> Issue Type: Bug
> Affects Versions: 3.8.2
> Reporter: Robert Scholte
> Priority: Critical
> Attachments: 381.log, 382.log
>
>
> The integrationtest of MJAVADOC-259 succeeds with Maven 3.8.1, but fails with
> 3.8.2.
> Git bisect identifies 76d5f0d942f52650d3bdf775b6af42d23d69066b as the first
> bad commit
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
