gnodet commented on code in PR #12694: URL: https://github.com/apache/maven/pull/12694#discussion_r4357255444
########## api/maven-api-core/src/main/java/org/apache/maven/api/build/report/LogEvent.java: ########## @@ -0,0 +1,189 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.maven.api.build.report; + +import java.time.Instant; + +import org.apache.maven.api.annotations.Experimental; +import org.apache.maven.api.annotations.Immutable; +import org.apache.maven.api.annotations.Nonnull; +import org.apache.maven.api.annotations.Nullable; + +/** + * A structured log event captured during the build. + * <p> + * Each event carries the log level, timestamp, message, and optionally + * the logger name and a stack trace. This replaces raw log line strings + * in the build report, enabling programmatic filtering by level and + * correlation by timestamp. + * <p> + * Events originating from the Maven Log API or from JUL + * ({@code java.util.logging}) carry additional source metadata: the + * source class name, source method name, and thread identifier. + * For Log API events the source class name is the mojo implementation + * FQCN; for JUL events it comes from {@code LogRecord}. Events from + * direct SLF4J logging have these fields set to {@code null}. + * + * @since 4.1.0 + */ +@Experimental +@Immutable +public interface LogEvent { + + /** + * When this log event was produced (wall-clock time). + * + * @return the event instant, never {@code null} + */ + @Nonnull + Instant timestamp(); + + /** + * The severity level of this log event. + * + * @return the log level, never {@code null} + */ + @Nonnull + LogLevel level(); + + /** + * The log message, without level prefix or timestamp formatting. + * + * @return the log message, never {@code null} + */ + @Nonnull + String message(); Review Comment: Good question. The design here separates two different use cases: - `message()` — the raw text, no format specifiers, no template placeholders. This is what SLF4J gives us after argument substitution (via `MessageFormatter.arrayFormat()`). Both JUL events (after `MessageFormat.format()`) and SLF4J events produce a fully substituted string. - `formattedMessage()` — the fully rendered console line: `[INFO] message\n` with optional ANSI, timestamp prefix, etc. We don't have the original template + args because SLF4J's `LoggingEvent` does carry them (`getMessage()`/`getArgumentArray()`), but JUL's `LogRecord` substitutes eagerly. Exposing a template+args API would mean SLF4J events could provide it but JUL events could not, creating an inconsistent interface. If you feel strongly about a template+args API: we could add `messageTemplate()` and `messageArgs()` default-null methods for the SLF4J path and document that they're unavailable for JUL events. But my concern is that consumers would have to implement two code paths — check if template+args are available, fall back to `message()` otherwise — adding complexity with little gain over just using `message()` everywhere. As for why we have both `message()` and `formattedMessage()`: `message()` is for programmatic consumers (build report filters, structured log exporters). `formattedMessage()` is for pass-through renderers that want to emit exactly what the terminal would have shown. They serve different audiences. I can drop `formattedMessage()` from the API interface (see Romain's other comment on that) and expose it only at the impl level if you agree. -- 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]
