gnodet opened a new issue, #13565:
URL: https://github.com/apache/maven/issues/13565
## Context
Maven uses SLF4J 2.0.20 which supports the fluent API with key-value pairs:
```java
logger.atWarn()
.addKeyValue("maven.diagnostic.key", "deprecated-source-target")
.addKeyValue("maven.diagnostic.suggestion", "Use release flag instead")
.setMessage("source/target 8 is deprecated")
.log();
```
The logging stack (PR #12694) auto-captures WARN-level log events and creates
synthetic `BuilderProblem` objects with hash-based keys
(`auto:logger-name:hash`).
These lack the structured metadata that `DiagnosticReporter` provides (key,
suggestion, documentationUrl).
## Proposal
Define a set of well-known SLF4J key-value key conventions:
| Key | Type | Description |
|-----|------|-------------|
| `maven.diagnostic.key` | String | Stable dedup key (e.g.,
`deprecated-source-target`) |
| `maven.diagnostic.suggestion` | String | Actionable fix text |
| `maven.diagnostic.documentationUrl` | String | Link to relevant docs |
| `maven.diagnostic.source` | String | Source file path |
| `maven.diagnostic.line` | int | Line number |
When `MavenSimpleLogger` captures a WARN event, it checks for these KV pairs
on the `LoggingEvent` and uses them to create richer `BuilderProblem` objects
instead of falling back to hash-based synthetic keys.
## Benefits
- Plugins can emit structured warnings using **standard SLF4J** without
depending
on `maven-api-core` or `DiagnosticReporter`
- Migration stepping stone: `Log.warn()` → SLF4J KV pairs → full
`DiagnosticReporter`
- JUL has no equivalent (no extensible KV support on `LogRecord`), but this
is
fine — JUL callers are external libraries, not Maven plugins
## Related
- #12694 — Logging foundation PR
- #12571 — Build output overhaul tracking issue
<!-- AI-Agent-Disclosure -->
> 🤖 Drafted with Claude Code (Claude Opus 4.6). Reviewed and confirmed by
@gnodet before submission.
--
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]
