gnodet commented on PR #12695: URL: https://github.com/apache/maven/pull/12695#issuecomment-5728970371
Looking at the bigger picture: could the architecture be simpler by leaning more on JUL rather than defining a new Maven API? JUL does offer a solid foundation — `Handler` receives everything and can filter/buffer/route, `LogRecord` carries level/timestamp/thread, and it's dependency-free. But there are a few gaps that can't be bridged without adding a layer on top: 1. **No session concept.** A `Handler` is JVM-global. For mvnd (multiple concurrent sessions in the same JVM), you'd need a demultiplexing mechanism to isolate "the logs of build A" from "the logs of build B" — which is exactly what the session-scoped `reportCapture` callback does today. 2. **`LogRecord` has no Maven fields.** `module`, `mojoId`, `executionId` don't exist in JUL. You could put them in the MDC (thread-local, lost on file write), stuff them into `LogRecord.setParameters()` (a hack), or encode them in the message (unparseable). Either way, you're adding a layer. 3. **No versioned public API.** A JUL `Handler` is internal plumbing. `BuildReport` in `maven-api-core` is a contract — extensions that want to read build logs programmatically need a stable API to depend on, not a global `Handler` to hook into. 4. **Lifecycle events aren't log events.** `RichBuildEventListener` reacts to `projectStarted`, `mojoStarted`, `projectFinished` to drive its status display and conditional log suppression. JUL has no equivalent — those callbacks need to come from somewhere regardless. So the architecture *could* use JUL more heavily internally (e.g. replace `LogEventSink` with a `Handler`) but it can't eliminate the Maven layer above it. Maven concepts — session, module, mojo, lifecycle — have no JUL equivalent and have to be modeled somewhere. The real question is where. The current approach (SLF4J + MDC for transport, `LogEvent` as the structured type, `BuildEventListener` as the Maven-aware interface) is roughly equivalent in complexity to a JUL-centric alternative — it just uses SLF4J as the backbone instead of JUL directly. Since Maven already depends on SLF4J anyway, the gain from switching would be marginal. -- 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]
