[#756] Add verbose option to restore pre-3.6.1 logging

[pan3793]

Fixes #756.

MSHADE-479 (3.6.1) demoted several info logs to debug. This adds a verbose plugin option (property shade.verbose, default false) that logs those messages at info level again, without requiring mvn -X:

• Including <artifact> in the shaded jar.
• Excluding <artifact> from the shaded jar.
• Skipping pom dependency <artifact> in the shaded jar.
• Replacing <old> with <new>
• No artifact matching filter <artifact>

With verbose=false (default) they remain at debug level, keeping the 3.6.1+ behavior.

Adds an IT (src/it/projects/verbose-logging) asserting the include/exclude lines appear at info level when verbose=true.

Assisted-by: Claude Opus 4.6

[pan3793]

MSHADE-479 change suprised many users, since reverting is rejected by @elharo, I'd like to make it at least configurable.

cc @slawekjaranowski, @martinpaljak

[elharo]

This is unnecessary complexity. There is a switch to turn these messages on if you need them. It's the log level. I don't want a combinatorically exploding list of switches to configure every possible idiosyncratic combination of log messages.

[pan3793]

Log level is not an adequate switch here. Maven has no per-plugin log level on the command line; -X floods the build with thousands of debug lines from every plugin and Maven core to recover five lines of output. Telling users to diff a -X log is not a workable answer for something they read on every release build.

And the claim that this avoids complexity is not borne out downstream: MSHADE-479 did not remove complexity, it moved it onto every user who relied on the output. Apache Kyuubi and Apache Spark stayed on 3.6.0 and now explicitly override the ASM version to keep Java 25 compatibility, solely to preserve this output. Apache Flink upgraded but restores the old behavior by configuring a plugin-specific logger level in its CI pipeline. Three major projects maintaining workarounds is strictly more complexity than one boolean parameter in the plugin.

This is also not "combinatorial explosion". It is one flag restoring behavior the plugin shipped for ~15 years, following a well-established convention: maven-compiler-plugin, maven-javadoc-plugin, and maven-dependency-plugin all have verbose. The messages matter because shading is not transparent: the include/exclude list is how users audit the jar they publish. That is informational output about the produced artifact, not debug noise.

Default stays false, so users who wanted a quiet build lose nothing. A default-off opt-in that unblocks multiple downstream projects is not complexity worth vetoing.

Given the demand in #756, on #233, and the downstream impact above, I ask that this PR be reopened and the decision deferred until more maintainers and affected users have weighed in, rather than settled by a single early veto.

[pan3793]

also sent a mail to the dev_at_maven list https://lists.apache.org/thread/jt6q8jo2ps0x3yf1zf3tbj0m8xgkw5lb

[elharo]

I'll reopen and reconsider but so far I've seen demand from exactly 1 person. That's not sufficient. If you have references to the changes this imposes on downstream, please provide them. For now a plugin-specific logger level sounds like a reasonable workaround though I will note that depending on log messages for anything is a recipe for breakage and pain. That's not just in this plugin. That's not just in Maven. That's not just in Java. It's a really brittle antipattern. Log messages are not API and shouldn't be used as such. If you're doing that, you're going to have a bad day.

[elharo]

This feels like you're reinventing log levels.

[elharo]

If a project wants to audit what's in the jars they produce, the right way is to look in the jars they produce, not to rely on log messages.

[elharo]

From the Apache Spark, PR I don't see evidence that Apache Spark can't upgrade. You said you didn't like it so they didn't take the upgrade. Did anything actually break with the upgrade? What?

[elharo]

The Kyubi one is a little more significant. I'll assume they have a reason to write their own license checker instead of using the RAT plugin but there are still a lot of design issues here that compound on each other. I suspect they should be looking at the inputs to their build process instead of some random log messages somewhere in the middle.

This whole discussion does feel like a classic example of Hyrum's Law. "With a sufficient number of API users, all observable behaviors of your system will be depended on by somebody." I have enough trouble convincing the Maven Project to maintain a stable public API. I certainly don't want to promise that the log messages and log format are stable.

[martinpaljak]

I'd still split the notions of logging (constant, and level matters) from "user experience setting" for a tool. And the "user interface" is the log/output for a build plugin tool. Given that one of the main tasks of shade plugin is bundling many dependencies into a single jar, the information about which get included and which not, seems like "relevant information" (vs for example reasons of including or not including, which could be considered debug level detail). YMMV, I can happily live the way it is now, but it would be a neat addition. Like unix tools have a -v option even if they emit stuff into syslog.