Fwiw, structured logging is being worked on at https://github.com/apache/maven/pull/12695 Reviews welcomed.
Le mar. 8 sept. 2026 à 14:49, Romain Manni-Bucau <[email protected]> a écrit : > for not human case we should embrase structured logging (whatever it is > json - my preferred format since it embraces the whole ecosystem - or > logfmt) so we can inject structured data in the output lines (a bit like > SSE for people knowing it better) > but totally agree shade logs were designed for humans and are very useful > to spot configuration and changes in dependencies when working on packaging > so must be in info level to stay usable an be user friendly. > > 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 mar. 8 sept. 2026 à 13:20, Hervé Boutemy <[email protected]> a écrit > : > > > you call a human looking at logs "parsing"? > > > > is it ideal? no > > but making users life harder is not the right answer while working on > more > > ambitious options > > when this simple parameter can help soft transitioning > > > > notice: I need the more ambitious options for future other needs, where > > I'll probably need parsing or equivalent not-human oriented approach > > pointers welcome > > > > On 2026/09/08 10:16:51 Elliotte Rusty Harold wrote: > > > Logging != API. The reason people are (or one person is?) having > > > trouble with the logs not being there is that they're using logs for > > > something they were never intended for. Writing code that depends on > > > log messages is brittle and not something we want to support and > > > commit to. > > > > > > I've looked at the specific issues involved here and parsing the logs > > > is not what they should be doing in the first place. There are other > > > and better ways to accomplish what they want. > > > > > > -10 > > > > > > On Tue, Sep 8, 2026 at 6:39 AM Hervé Boutemy <[email protected]> > > wrote: > > > > > > > > I fully agree: it's a matter of taste to have that information at > INFO > > level or not > > > > > > > > for people who have strong taste against INFO, I'm ok with default > > value hiding from INFO > > > > > > > > PR looks reasonable to get that feature (given how DEBUG log is > > definitively unusable) for people who prefer INFO > > > > > > > > Regards, > > > > > > > > Hervé > > > > > > > > On 2026/09/04 11:59:34 Cheng Pan wrote: > > > > > Hi all, > > > > > > > > > > MSHADE-479 (shipped in 3.6.1, PR [1]) demoted several shade mojo > > info logs to debug, notably: > > > > > > > > > > - Including <artifact> in the shaded jar. > > > > > - Excluding <artifact> from the shaded jar. > > > > > - Skipping pom dependency <artifact> in the shaded jar. > > > > > > > > > > This output had been at info level for ~15 years and is how users > > audit what actually goes into the artifact they publish. Shading is not > > transparent: the final content is decided by artifactSet/filter > evaluation, > > and the include/exclude list is the only direct record of that decision. > > > > > > > > > > Since 3.6.1 the only way to see it is mvn -X, which drowns five > > relevant lines in thousands of debug lines from Maven core and every > other > > plugin. Maven offers no per-plugin log level on the command line. > > > > > > > > > > Downstream impact so far: > > > > > > > > > > - Apache Spark explicitly dropped maven-shade-plugin from a bulk > > plugin-upgrade PR to stay on 3.6.0 [2][3], and pins the ASM version in > its > > pom to keep Java 25 support on the old plugin version [4]. > > > > > - Apache Kyuubi likewise stays on an older plugin version with an > > ASM 9.8 pin, carrying a TODO to remove it once an upstream release makes > > that unnecessary [5]. > > > > > - Apache Flink upgraded to 3.6.1 and their license compliance > > tooling broke: the LicenseChecker parses the "Including ..." lines to > > validate NOTICE files. They restored the output by forcing the plugin's > > logger > > > > > to debug level in CI, stating "I could not find any other way to > > print these lines" [6], backported it [7], and then needed a follow-up to > > clean up the debug-log noise this introduced [8]. > > > > > > > > > > - User demand: issue [9] and multiple comments on PR [1]. > > > > > > > > > > Proposal: add a boolean "verbose" parameter (property > shade.verbose, > > default false) that logs these messages at info level when enabled. > Default > > off, so the quiet-build behavior introduced by MSHADE-479 is unchanged. > > Precedent exists in maven-dependency-plugin (verbose on tree/analyze, > > silent on other goals), and users already know the <verbose> convention > > from compiler and javadoc plugins. > > > > > > > > > > A PR implementing this is available [10]. It was closed as > > "unnecessary complexity". I believe a default-off opt-in that unblocks > > multiple downstream ASF projects deserves broader input, hence this > thread. > > > > > > > > > > [1] https://github.com/apache/maven-shade-plugin/pull/233 > > > > > [2] > > https://github.com/apache/spark/pull/52622#issuecomment-3407500888 > > > > > [3] > > https://github.com/apache/spark/pull/52622#issuecomment-3407616785 > > > > > [4] > https://github.com/apache/spark/blob/master/pom.xml#L3087-L3103 > > > > > [5] > https://github.com/apache/kyuubi/blob/master/pom.xml#L1596-L1615 > > > > > [6] https://github.com/apache/flink/pull/27261 > > > > > [7] https://github.com/apache/flink/pull/27266 > > > > > [8] https://github.com/apache/flink/pull/27722 > > > > > [9] https://github.com/apache/maven-shade-plugin/issues/756 > > > > > [10] https://github.com/apache/maven-shade-plugin/pull/849 > > > > > > > > > > Please share your thoughts. If the feedback is positive I will > > follow up with a [VOTE] thread or simply reopen the PR, whichever the > > community prefers. > > > > > > > > > > Thanks, > > > > > Cheng Pan > > > > > > --------------------------------------------------------------------- > > > > > 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] > > > > > > > > > > > > > -- > > > Elliotte Rusty Harold > > > [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] > > > > > -- ------------------------ Guillaume Nodet
