gnodet edited a comment on pull request #578: URL: https://github.com/apache/maven/pull/578#issuecomment-940689897
> I confirm that #476 seems to fix [MNG-6843](https://issues.apache.org/jira/browse/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. Yes, obviously. What I meant was _less_ delay, because of the finer grained lock. > > What I don't fully understand yet: When is `ProjectStarted` fired, especially in the case for an aggregating execution (which involves multiple projects)? The `ProjectStarted` is fired when a project's build is began, i.e. once for a given project in a reactor, whereas during an aggregating execution, there's the notion of _forked lifecycle_, and the `ForkedProjectStarted` event is fired from inside the `MojoExecutor`. -- 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]
