It was not my intention to offend anyone, of course one person's noise is another person's preferred music. I probably need to dive a bit more into https://maven.apache.org/maven-logging.html
Mit freundlichen Grüßen Mirko Friedenhagen — Mit freundlichen Grüßen Mirko Friedenhagen — > Am 05.10.2026 um 08:06 schrieb Hervé Boutemy <[email protected]>: > 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]
