+1 these logs where helpful and if you arent happy with info level you can make maven quiet anyway
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 à 08:39, Hervé Boutemy <[email protected]> a écrit : > 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] > >
