Hi Martin, There is the common hack to fill these info manually like in any facade but agree it would have been simpler but not sure we want to be back in 2022 (for a recent one "Logging in Maven Plugins - Bridging") or even ~2015.
That said it doesn't solve all issues like conflicts with mojos (same for all mainstream API) so current option is not that bad and avoids the debate of the backend to use. The main issue with JUL is you need to switch the "backend" very quickly to be relevant (one reason we did Yupiik Logging Manager - https://www.yupiik.io/yupiik-logging/jul-integration.html) or do some custom integration to be as powerful than other cause defaults are not very friendly to integration or prod (even file handler is too limited and is slow). With SLF4J the good thing is you can switch jars and get it all almost for free but it has cons and we don't want to leak our impl as an API so MOJO logging facade was the compromise since JUL as an API was rejected - System.Logger would have been the same if it was an option in early discussions. So lon story short, JUL is a better API, sure, but will need a custom backend by default anyway. Having our custom facade is not that bad for MOJO (ultimately extensions) since it will enable to also put there MDC/NDC whereas JUL will need a custom one anyway and all other are impl details of "maven-core" so think we did our homework and don't think we need to start again this debate. Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino <https://javaccino.dev/> founder (Java/.NET service - contact via linkedin) Le dim. 4 oct. 2026 à 10:26, Martin Desruisseaux via dev < [email protected]> a écrit : > Le 04/10/2026 à 09:54, Claude Warren a écrit : > > > Yes you can change logging on the fly but the point in time where you > > realize you need detailed logging is after the event has happened. Hence > > the capture everything and figure out what to write at the end of some > sort > > of time box strategy strategy > > In my opinion, a Maven problem is that it chooses to reinvent its own > Logging interface instead of using java.util.logging (no need for > external dependencies such as SL4FJ. The java.util.logging API is rich > enough). The Maven interface is very minimalist, while the > java.util.logging API collects much more information: source class, > source method, thread ID, timestamp, etc. It also defines a XML format > where all those information can be saved: > > > https://docs.oracle.com/en/java/javase/25/core/java-logging-overview.html#GUID-84971801-F327-4F96-8F35-DA4D6737F857 > > Using java.util.logging in Maven would have allowed to show only the > most important log records in the console and optionally save more > records in an XML file. Users would have richer information for > filtering records in that file. > > Using the Maven Logging interface as a facade for java.util.logging does > not fully work. Java logging uses reflection for filling automatically > the source class and source method information. When using a facade, > java.util.logging thinks that all log records come from the facade. > Information about the real originator of the log record is lost. > > Martin > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
