ok, it seems some people really try to understand, I'll have to explain a little bit what may justify some logs by default: when the operation that a plugin goal runs has some network connexion, that may take time, having output to see a progression during build and not feel that the plugin is stuck is useful
of course, in a CI, you don't see that in the log at the end of the build but as a user on CLI, it is useful people just need to stop judging but ask the 5 whys and be tolerant when they initially don't understand: again, if it was done in a way, there was a reason and accept that they can ignore what they don't understand but it does not cause such a big issue and give some clarity about what plugin is offending, and the project using it if they don't get why this plugin is used whatever the tech details of logging, there has to be defaults and there has to be tolerance on use cases that differ from people to people for people really interested, I'll point to the case: https://github.com/apache/maven-artifact-plugin/blame/master/pom.xml#L274 Le lundi 5 octobre 2026, 09:01:58 heure d’été d’Europe centrale Björn Raupach a écrit : > What about changing the log level from INFO to DEBUG? > > That way, only those few that are interested need to change the log > level to see the required output, while everyone else sees nothing. > > Am 05.10.2026 08:06 schrieb Hervé Boutemy: > > 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-9781 > >> > 788473064> 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] > > --------------------------------------------------------------------- > 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]
