Context
PR #12572 (Build Report Foundation) introduced a warning collection pipeline that intercepts SLF4J WARN-level log calls via BuildReportCollector.captureLogEvent() and auto-creates BuilderProblem objects with synthetic keys (auto:xxx).
However, Maven already creates structured BuilderProblem objects during model/settings/toolchains validation (with key, suggestion, documentationUrl, source:line:column) and plugin validation (deprecated mojos, Maven 2 dependencies, etc.). These are currently re-logged as plain text, losing all structured metadata.
Problem
When the SLF4J hook intercepts the re-logged text, it creates a new synthetic BuilderProblem with:
- An auto-generated key (
auto:logger-name:hash) instead of the original meaningful key
- No
suggestion
- No
documentationUrl
- No source location
The original structured BuilderProblem data is discarded.
Implementation Status
✅ Done — Plugin validation (PR #12647)
PR #12647 implements structured BuilderProblem piping for all plugin validation pathways:
| Pathway |
Component |
Status |
| 1 — Model validation |
DefaultModelProblemCollector |
✅ Verified existing |
| 2 — Plugin parameter validation |
AbstractMavenPluginParametersValidator (3 validators) |
✅ Implemented |
| 3 — Plugin dependency validation |
AbstractMavenPluginDependenciesValidator (4 validators) |
✅ Implemented |
| 4 — Contextualizable check |
DefaultMavenPluginManager |
✅ Implemented |
| 5 — PluginValidationManager API |
Migrated from String → BuilderProblem |
✅ Implemented |
Additionally, PluginValidationManager was migrated to accept BuilderProblem natively, with deprecated String-based default methods for backward compatibility.
🔲 Remaining — Settings and toolchains validation
In LookupInvoker and MavenInvoker, settings/toolchains BuilderProblem objects are still re-logged as text before being captured. Same pattern as above — pipe the original BuilderProblem directly instead of only logging the message text.
Validators affected
| Validator |
Status |
DefaultModelValidator (~35 sites) |
✅ Already structured (Pathway 1) |
DeprecatedPluginValidator |
✅ PR #12647 |
Maven2DependenciesValidator |
✅ PR #12647 |
Maven3CompatDependenciesValidator |
✅ PR #12647 |
MavenScopeDependenciesValidator |
✅ PR #12647 |
MavenMixedDependenciesValidator |
✅ PR #12647 |
ReadOnlyPluginParametersValidator |
✅ PR #12647 |
DeprecatedCoreExpressionValidator |
✅ PR #12647 |
DefaultSettingsValidator (~15 sites) |
🔲 Remaining |
DefaultToolchainsBuilder |
🔲 Remaining |
| Profile activators (File, JDK) |
🔲 Remaining |
Expected Outcome
mvnlog --diagnostics displays full structured information:
Problems: 2 warnings
[WARN] 'prerequisites' is deprecated pom.xml
key: deprecated-prerequisites
suggestion: Use the maven-enforcer-plugin instead
docs: https://maven.apache.org/pom.html#prerequisites
[WARN] Plugin uses deprecated Maven 2 API maven-shade-plugin:3.5.0
key: plugin-maven2-dependency
suggestion: Update to a version that uses Maven 4 API
Depends on
Context
PR #12572 (Build Report Foundation) introduced a warning collection pipeline that intercepts SLF4J WARN-level log calls via
BuildReportCollector.captureLogEvent()and auto-createsBuilderProblemobjects with synthetic keys (auto:xxx).However, Maven already creates structured
BuilderProblemobjects during model/settings/toolchains validation (withkey,suggestion,documentationUrl,source:line:column) and plugin validation (deprecated mojos, Maven 2 dependencies, etc.). These are currently re-logged as plain text, losing all structured metadata.Problem
When the SLF4J hook intercepts the re-logged text, it creates a new synthetic
BuilderProblemwith:auto:logger-name:hash) instead of the original meaningful keysuggestiondocumentationUrlThe original structured
BuilderProblemdata is discarded.Implementation Status
✅ Done — Plugin validation (PR #12647)
PR #12647 implements structured
BuilderProblempiping for all plugin validation pathways:DefaultModelProblemCollectorAbstractMavenPluginParametersValidator(3 validators)AbstractMavenPluginDependenciesValidator(4 validators)DefaultMavenPluginManagerString→BuilderProblemAdditionally,
PluginValidationManagerwas migrated to acceptBuilderProblemnatively, with deprecated String-based default methods for backward compatibility.🔲 Remaining — Settings and toolchains validation
In
LookupInvokerandMavenInvoker, settings/toolchainsBuilderProblemobjects are still re-logged as text before being captured. Same pattern as above — pipe the originalBuilderProblemdirectly instead of only logging the message text.Validators affected
DefaultModelValidator(~35 sites)DeprecatedPluginValidatorMaven2DependenciesValidatorMaven3CompatDependenciesValidatorMavenScopeDependenciesValidatorMavenMixedDependenciesValidatorReadOnlyPluginParametersValidatorDeprecatedCoreExpressionValidatorDefaultSettingsValidator(~15 sites)DefaultToolchainsBuilderExpected Outcome
mvnlog --diagnosticsdisplays full structured information:Depends on