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-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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
