gnodet commented on code in PR #12694: URL: https://github.com/apache/maven/pull/12694#discussion_r4357318405
########## 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 short answer: there's no consistent template available from all three input paths. JUL's `LogRecord` does carry `message` + `parameters[]` for `MessageFormat` substitution, but once `MavenJulHandler` calls `Formatter.formatMessage(record)` those two are merged into a single string — there's no going back. SLF4J's `LoggingEvent` does carry the template and args separately (`getMessage()`/`getArgumentArray()`), so we _could_ expose them for SLF4J events, but JUL events would always return `null` args. Consumers would need to branch: check for template → fall back to substituted message, adding complexity for no real gain. The split between `message()` and `formattedMessage()` serves two different audiences: - `message()` — raw substituted text, for structured consumers (filters, build reporters, JSON exporters) - `formattedMessage()` — exactly what the terminal would have printed (level prefix, timestamp, thread, ANSI), for pass-through renderers That said, I agree that `formattedMessage()` is really a renderer concern and arguably doesn't belong on the event interface. See reply at line 108 for the planned direction. -- 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]
