Logging and Tracing Policy for Maven
Discussion: https://github.com/support-and-care/maven-support-and-care/discussions/174
Original Item: "Logging, Tracing Policy (Gerd)"
Problem Statement
Maven's current logging output is often too verbose at the INFO level for typical builds, yet lacks sufficient detail for troubleshooting complex issues. There is no consistent policy defining which events should be logged at which level. While the underlying logger supports trace logging, there is no CLI switch to easily enable it. Developers struggling with build issues have limited visibility into Maven's internal operations.
Current State / Starting Point
- Maven uses SLF4J with a simple logger implementation
- INFO level output includes many details that could be DEBUG/TRACE
- Trace logging can be activated via system properties, but this is not user-friendly
- No standardized approach for categorizing log events by severity
Expected Outcomes / Benefits
-
Logging Policy Definition: Establish clear guidelines for which events belong at which log level (ERROR, WARN, INFO, DEBUG, TRACE)
-
Reduced Verbosity: Make Maven less verbose at INFO level for cleaner build output in normal operation
-
CLI Trace Switch: Add a proper CLI option (e.g.,
-Xenhancement or new flag) to enable trace-level logging for deep problem analysis
Note: A metrics collection for goal execution timing and performance analysis is covered by Build Observability and Reporting.
Discussion Summary
The community broadly agreed on reducing INFO-level verbosity. Maven 4 already adds per-plugin debug logging, which partially addresses the need. Challenges were raised around logging in parallel and forked execution scenarios where output interleaving can make logs hard to read. It was noted that Maven 4 may already address some of these concerns, so the scope should be validated against the current Maven 4 state.
Final Discussion (2026-02-24)
- Write docs and implement (perhaps with some automation like with Open Rewrite)
- Decision: Request Funding