gnodet commented on PR #12695: URL: https://github.com/apache/maven/pull/12695#issuecomment-5694854494
JUL is indeed used as the backend (see #12694 which adds a JUL handler). The thin abstraction on top (`LogEvent`/`LogEventSink`) exists for two reasons JUL alone can't address: 1. **ClassRealm is the wrong isolation boundary.** A single plugin ClassRealm can be shared across multiple parallel executions (e.g. `maven-compiler-plugin` running on 4 modules with `-T4`). Routing by ClassRealm would mix their logs. We need thread-based routing tied to the current mojo execution context. 2. **The build report isn't a log file.** It's a structured document (modules → executions → results + timing + log events) assembled *during* the build via `EventSpy` lifecycle hooks. A JUL JSON formatter would give you a flat event stream — you'd still need to correlate it with Maven lifecycle events to reconstruct per-mojo timing and results, which is exactly the complexity we're avoiding. So it's less "yet another logging abstraction" and more "a thin bridge between the JUL stream and the Maven execution model." -- 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]
