Fix duplicate model problem reporting, fixes #12691

[Mazen050]

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.

Summary

Fixes #12691 by removing the duplicate rendering of model problems introduced in ProjectBuildingException#createMessage(...).

The detailed per-project diagnostics were added to the exception message in #10975. However, DefaultExceptionHandler already reconstructs and renders the same information from ProjectBuildingException#getResults(), so the new exception message caused the same diagnostics to be printed twice.

This change restores the previous behavior by reverting ProjectBuildingException#createMessage(List<ProjectBuildingResult>) to return the short summary message, leaving the existing rendering in DefaultExceptionHandler as the single source of detailed diagnostics.

ProjectBuildingExceptionTest is removed because it was introduced to validate the detailed formatting added in #10975. Reverting that behavior makes the test obsolete; the remaining behavior is simply returning the generic exception message.

Before

[ERROR] 3 problems were encountered while processing the POMs (3 errors):

[pom.xml]
  [FATAL] 'modelVersion' of '99.0.0' is newer than the versions supported by this Maven version (4.0.0-rc-6). …
  [ERROR] Malformed POM …: Unrecognised tag: '…invalidElementShouldFailBuild' @ …/pom.xml
  [ERROR] Failed to load project …/pom.xml

[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR]   The project (…/pom.xml) has 3 errors
[ERROR]     'modelVersion' of '99.0.0' is newer than the versions supported by this Maven version (4.0.0-rc-6). …
[ERROR]     Malformed POM …: Unrecognised tag: '…invalidElementShouldFailBuild': ParseError at [row,col]:[8,3]
[ERROR]     Message: Unrecognised tag: '…invalidElementShouldFailBuild'
[ERROR]     Failed to load project …: 2 problems were encountered while building the effective model
[ERROR]         - [FATAL] 'modelVersion' of '99.0.0' …
[ERROR]         - [ERROR] Malformed POM …

After

[ERROR] Some problems were encountered while processing the POMs
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]   
[ERROR]   The project (/workspaces/maven/maven-repro/pom.xml) has 3 errors
[ERROR]     'modelVersion' 99.0.0' is not supported by this Maven version (4.1.0-SNAPSHOT). Supported modelVersions are: [4.0.0, 4.1.0, 4.2.0]. Building this project requires a newer version of Maven. @ test:fail-build:0.1-SNAPSHOT, file:///workspaces/maven/maven-repro/pom.xml, line 2, column 3
[ERROR]     Malformed POM /workspaces/maven/maven-repro/pom.xml: Unable to read model: Unrecognised tag: '{http://maven.apache.org/POM/4.0.0}invalidElementShouldFailBuild': ParseError at [row,col]:[7,3]
[ERROR]     Message: Unrecognised tag: '{http://maven.apache.org/POM/4.0.0}invalidElementShouldFailBuild'
[ERROR]     Failed to load project /workspaces/maven/maven-repro/pom.xml @ org.apache.maven:maven-toolchain-builder:4.1.0-SNAPSHOT, /workspaces/maven/compat/maven-toolchain-builder/pom.xml: 2 problems were encountered while building the effective model
[ERROR]         - [FATAL] 'modelVersion' 99.0.0' is not supported by this Maven version (4.1.0-SNAPSHOT). Supported modelVersions are: [4.0.0, 4.1.0, 4.2.0]. Building this project requires a newer version of Maven. @ line 2, column 3
[ERROR]         - [ERROR] Malformed POM /workspaces/maven/maven-repro/pom.xml: Unable to read model: Unrecognised tag: '{http://maven.apache.org/POM/4.0.0}invalidElementShouldFailBuild'
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the '-e' switch
[ERROR] Re-run Maven using the '-X' switch to enable verbose output
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException

Each model problem is now reported once again, matching the pre-4.0.0-rc-6 behavior.

Note: Please consider backporting this change to maven-4.0.x, as it fixes a regression affecting the 4.0.x release line.

[gnodet]

Clean, well-scoped fix for the duplicate model problem reporting regression introduced in #10975. The root cause is correctly identified: DefaultMaven.buildGraph() logs problem details from ModelProblem.getMessage() (which falls back to the exception message when its own message is null), and then DefaultExceptionHandler independently rebuilds the same details from getResults(), producing every model problem twice.

Reverting the exception message to the short static string is the right fix — it targets the duplication at its source without changing the higher-risk logging or exception handling paths. The test deletion is appropriate since all five methods validated the detailed message formatting being removed.

Worth noting: the regression was also backported to maven-4.0.x via commit b8a0ae0, so a backport of this fix is warranted there as well.

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

Claude Code on behalf of gnodet

[rmannibucau]

Can be worth a test showing the fixed issue to ensure it doesn't come back, the pr just validates an impl detail not the feature so bug can pop up again any time IMHO

[Mazen050]

Hello, I added the test.

The test covers both paths directly: it verifies that ProjectBuildingException.getMessage() remains the short summary, while DefaultExceptionHandler still renders the problem detail exactly once. That way it catches both the original regression and any future regression where the handler stops showing the detail.

[gnodet]

The new regression test properly addresses @rmannibucau's feedback — it validates user-facing behavior (no duplicate error rendering in console output), not just implementation details.

What the test covers:

• Exercises the real DefaultExceptionHandler.handleException() pipeline (the same code path used by MavenInvoker.doExecute() in production)
• Verifies ProjectBuildingException.getMessage() returns only the short summary (preventing duplication when logged alongside handler output)
• Verifies the handler's ExceptionSummary tree contains each problem detail exactly once via countOccurrences(flatten(summary), ...)
• The flatten() helper simulates what MavenInvoker.logSummary() does in production

The original fix remains correct and complete. The deletion of ProjectBuildingExceptionTest is appropriate since it tested the detailed formatting behavior introduced in #10975, which this PR reverts.

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

Claude Code on behalf of gnodet