slachiewicz opened a new pull request, #12706:
URL: https://github.com/apache/maven/pull/12706

   Backport of #12705 to `maven-4.0.x`. Fixes #12704 on the release branch — 
the code is identical there, so the bug ships in 4.0.0-rc-4 through rc-6.
   
   The cherry-pick applied without conflicts.
   
   ### What it fixes
   
   `BuildPlanExecutor`'s `TEARDOWN` decided between `ProjectSucceeded` and 
`ProjectSkipped` on `allStepsExecuted`, which required *every* step of a 
project's plan to have reached `EXECUTED`. The plan holds a step for every 
phase of the lifecycle regardless of the requested tasks, so a project keeps 
empty steps for the phases beyond them; a halted reactor skips those, and a 
project that had already finished everything asked of it was reported as 
skipped. The decision is now based on the steps that carry mojo executions, 
plus a check that the project's `SETUP` ran at all.
   
   The accompanying log line always blamed a failed dependency, which is untrue 
for a project stopped by an unrelated failure. `ExecutionEventLogger` now tells 
the two cases apart.
   
   ### Verification on this branch
   
   - Repro (two independent modules, one failing, one with 4000 sources still 
compiling): 3 runs out of 3 — the independent module compiles its 4001 sources, 
writes its 4000 class files and is reported as succeeded; only the module that 
genuinely depends on the failed one is skipped, with the dependency wording.
   - `MavenITmng8648ProjectEventsTest` passes against the patched 
4.0.0-SNAPSHOT distribution: `subproject-a` and `subproject-b` succeed, 
`subproject-c` fails, `subproject-d` is skipped and keeps the dependency 
message.
   - Unit tests of `impl/maven-core` and `impl/maven-cli` are green (621 
tests), `spotless:check` clean.
   
   ### Not addressed here
   
   `MavenITmng8648ProjectEventsTest` stays timing-sensitive: if `subproject-c` 
fails before `subproject-b`'s steps are scheduled at all, `b` is legitimately 
skipped and the assertion on `ProjectSucceeded` still fails. That needs an 
ordering guarantee in the test rather than a change in core.
   


-- 
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]

Reply via email to