fix: make stdout/stderr log level follow -q/--quiet option (#12730)

[waterWang]

Summary

Fixes #12730 — mvn --quiet does not honor the -q/--quiet option.

Root cause

In LookupInvoker.doConfigureWithTerminalWithRawStreamsDisabled(), the stdout and stderr loggers were hardcoded to LocationAwareLogger.INFO_INT, ignoring the active log level set by the -q/--quiet option. When -q is passed, context.loggerLevel is set to ERROR, but the stdout logger remains at INFO, so [INFO] [stdout] ... lines still appear (e.g. from help:evaluate -DforceStdout).

Fix

Derive the stdout/stderr log level from context.loggerLevel instead of hardcoding INFO:

• -q/--quiet → ERROR (suppresses [INFO] [stdout] prefix)
• default → INFO (unchanged behavior)
• -X/--debug → DEBUG

Impact

• mvn --quiet help:evaluate -Dexpression=X -DforceStdout now prints just the value, without the [INFO] [stdout] prefix.
• No behavior change for non-quiet invocations.

[gnodet]

The root cause analysis is correct — the [INFO] [stdout] prefix is unwanted in quiet mode. However, the fix has a critical logic error that makes it strictly worse than the current behavior:

stdout/stderr completely suppressed in quiet mode

Setting stdout.setLogLevel(ERROR_INT) raises the logger threshold to 40. But the logging calls are unchanged:

• stdout.info("[stdout] " + s) — INFO_INT (20) < ERROR_INT (40) → isLevelEnabled() returns false → entire message silently dropped
• stderr.warn("[stderr] " + s) — WARN_INT (30) < ERROR_INT (40) → same result

This means mvn --quiet help:evaluate -DforceStdout would produce zero output instead of the current [INFO] [stdout] <value>. The user's content (the actual evaluated value) is discarded along with the prefix.

The SLF4J level gate in MavenBaseLogger.isLevelEnabled() (line 251–254: return logLevel >= currentLogLevel) prevents any message below the logger's current level from being emitted.

Possible approaches

A correct fix would need to either:

• Bypass the SLF4J level check for stdout/stderr passthrough (write directly to the terminal in quiet mode, similar to how doConfigureWithTerminalWithRawStreamsEnabled handles it)
• Change the consumer lambda to use a raw write for content while suppressing only the decorative prefix
• Use a dedicated output path that isn't level-gated

Missing tests

No tests were added to verify the new behavior. A test that checks stdout content passes through in quiet mode would have caught this issue.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of gnodet

[gnodet]

The root cause analysis is correct — stdout/stderr loggers should respect -q/--quiet. However, the fix introduces a regression: in quiet mode, stdout and stderr content is silently discarded entirely, not just the prefix.

Critical issues:

1. [high] stdout content silently dropped — Setting the stdout logger to ERROR_INT (40) causes stdout.info("[stdout] " + s) (INFO_INT = 20) to be completely suppressed by MavenBaseLogger.isLevelEnabled() (20 >= 40 = false). User content (e.g. from help:evaluate -DforceStdout) is silently discarded along with the prefix, not just the prefix as the PR description claims.

2. [high] stderr content silently dropped — Same mechanism: stderr.warn("[stderr] " + s) uses WARN_INT (30) which is also below ERROR_INT (40), so stderr content is also completely discarded in quiet mode.

3. [medium] Approach fundamentally flawed — The SLF4J level check occurs before handleNormalizedLoggingCall() is invoked, so the logger level mechanism gates the entire message (prefix + user content). Adjusting the logger level alone cannot solve this problem. A correct fix needs to bypass the SLF4J level check for stdout/stderr passthrough — e.g., writing directly to the terminal, using a raw write path, or conditionally stripping just the prefix.

4. [medium] No tests — No tests were added to verify the new behavior. A test asserting stdout content passes through in quiet mode would have caught this regression.

This review was generated by an AI agent (Claude Code) and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of Guillaume Nodet