In failed build limit reactor summary to only failed modules

[slawekjaranowski]

When build fail in multimodule project we need scroll many lines to see whats is wrong

based on: #11977

Following this checklist to help us incorporate your
contribution quickly and easily:

• Your pull request should address just one issue, without pulling in other changes.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body.
  Note that commits might be squashed by a maintainer on merge.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied.
  This may not always be possible but is a best-practice.
• Run mvn verify to make sure basic checks pass.
  A more thorough check will be performed on your pull request automatically.
• You have run the Core IT successfully.

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
• In any other case, please file an Apache Individual Contributor License Agreement.

[gnodet]

Review Summary

This PR implements a useful UX improvement: in failed multi-module builds, the reactor summary is condensed to show only the failed modules with ... ellipsis markers replacing successful/skipped modules. The formatBuildTime extraction is a nice refactoring that eliminates code duplication, and the changes are correctly applied to both the compat and impl copies.

However, the ellipsis logic has a gap in the multi-failure scenario.

Issue: missing ellipsis between non-adjacent failures

In a --fail-at-end build with modules M1(root,success), M2(fail), M3(success), M4(success), M5(fail), M6(skipped), M7(skipped):

The ... separator is only printed when project.isExecutionRoot() is true inside the shouldSkip block. Since only M1 is the execution root, the output would be:

...
M2 .................. FAILURE [1.234 s]
M5 .................. FAILURE [0.567 s]
...

Modules M3 and M4 (which succeeded between the two failures) are silently dropped with no visual separator. A more informative output would be:

...
M2 .................. FAILURE [1.234 s]
...
M5 .................. FAILURE [0.567 s]
...

Suggested fix: Replace the isExecutionRoot() guard with a "was previous module skipped?" tracking variable:

boolean lastWasSkipped = false;
for (MavenProject project : projects) {
    // ... determine shouldSkip ...
    if (shouldSkip) {
        lastWasSkipped = true;
        continue;
    }
    if (lastWasSkipped) {
        logger.info("...");
        lastWasSkipped = false;
    }
    // ... print module line ...
}
if (lastWasSkipped) {
    logger.info("...");
}

This applies to both the impl and compat copies.

Minor notes

• No test covers the multi-failure (--fail-at-end) scenario — adding one would validate the ellipsis placement between non-adjacent failures
• New test methods use public while existing tests use package-private (JUnit 5 convention in this codebase)

Overall the feature is valuable — the ellipsis logic just needs refinement for multi-failure correctness.

---

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of Guillaume Nodet

[Bukama]

Can we make this visual change configuarable?

[slawekjaranowski]

Can we make this visual change configuarable?

First I would like to have the same simple feature in all Maven version, next we can extend it

[slawekjaranowski]

@gnodet fix after review done

[gnodet]

Review Summary (re-review after new commit)

All three items from the previous review have been addressed:

1. Ellipsis gap fixed — the isExecutionRoot() guard was replaced with a lastWasSkipped tracking variable, which properly handles leading, trailing, and interleaved ellipsis markers between non-adjacent failures. This is exactly the approach suggested.
2. Test method visibility — corrected to package-private (JUnit 5 convention).
3. New test coverage — testSessionEndedFailureMultimoduleWithSeparatedFailures validates ellipsis placement between non-adjacent failures.

The lastWasSkipped approach is straightforward and correct. The formatBuildTime extraction is a nice de-duplication. Both impl and compat copies are kept in sync.

LGTM — clean follow-up.

Claude Code on behalf of Guillaume Nodet
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

[cstamas]

3.10.0 should receive these improvements too.