and to be clear: I recognize the log, I know which plugin it is, and which project was built that uses it and I know why this log is useful (and I know a few of us who do), because globally: no people who did this are not stupid as the feedback suggests
but I refuse to even try to justify when I see what happened to a user trying to be reasonable on shade output as it is clear that we currently have strong voices that do not respect feedback and other's taste Regards, Hervé On 2026/10/04 18:45:04 Hervé Boutemy wrote: > each plugin developer does his own choices, based on his feeling of needs: > it's not a Maven core plugin > > long copy paste of output, but not even the useful part to know what > plugin:goal it is about > > once we know the plugin, having a discussion with the plugin maintainer can > make sense > (please with respect, and not accusation of junk) > > Regards, > > Hervé > > On 2026/10/04 12:41:48 Romain Manni-Bucau wrote: > > 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] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
