famod commented on pull request #578: URL: https://github.com/apache/maven/pull/578#issuecomment-940512890
I confirm that #476 seems to fix MNG-6843 as well. I've built maven-3.8.x with that `LockingEventSpy` and there were no failures in https://github.com/famod/parallel-testbed/tree/compiler-fix 👍 Overall, I would prefer #476 over this because it also prevents inconsistencies in other places. It's also more fine grained in that it seems to reduce the locking scope to the actual project being executed whereas with my approach, all mojo executions have to wait for an aggregating execution, no matter which project they are about to be executed for. @gnodet > I think my proposal would not cause any delay in the build If a "regular" mojo execution wants to run for project A, but an aggregating mojo execution comes first, chances are that A is indeed locked and the other execution has to wait for that. So there will be a "delay" but there is no way around that, a lock is a lock. What I don't fully understand yet: When is `ProjectStarted` fired, especially in the case for an aggregating execution (which involves multiple projects)? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
