A common way to control "verbosity" in commandline application is having:
default : as silent as possible
-v : show some level of output (e.g. "Downloading dependencies ...")
-vv : show more (e.g. Start downloading / stop downloading)
-vvv : even more
This could easily adopted for other areas of maven, e.g.
[INFO] --- maven-compiler-plugin:3.10.1:testCompile
(default-testCompile) @ tycho-source-plugin ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 2 source files to
/home/christoph/git/laeubi/tycho/tycho-source-plugin/target/test-classes
[INFO] --- maven-jar-plugin:3.3.0:jar (default-jar) @
tycho-sourceref-jgit ---
[INFO] Building jar:
/home/christoph/git/laeubi/tycho/tycho-extras/tycho-sourceref-jgit/target/tycho-sourceref-jgit-4.0.0-SNAPSHOT.jar
[INFO] --- maven-surefire-plugin:3.0.0-M9:test (default-test) @
tycho-sourceref-jgit ---
[INFO] Tests are skipped.
[INFO] --- maven-plugin-plugin:3.7.1:descriptor (default-descriptor) @
tycho-source-plugin ---
[INFO] Using 'UTF-8' encoding to read mojo source files.
all these extra messages can be suppressed most of the time.
So a default maven run with lowest verbosity message maybe even just
print the following:
Building my.project:module1:123 ...
Building my.project:module2:345 ...
Building my.project:module3:345 ...
Build success!
Am 21.02.23 um 19:59 schrieb Elliotte Rusty Harold:
A general pattern I notice in discussions of excessive logging — not
just here and not only involving Maven — is to describe a scenario in
which a certain log message is useful. This is not hard to do but does
not justify the log message. Instead it is necessary to estimate how
often that log message will be read and acted on. Any log message that
is likely to be acted on less than 1% of the time (often a lot less)
should not be turned on by default. It does far more harm by hiding
real problems than it does by once in a blue moon giving someone
useful info.
The only log messages that should be shown to the developer by default
are ones that are expected to be acted on. For instance, a failed
assert in a unit test should be logged because the whole point of
running a unit test is to fix failures. However a passed assertion
should log absolutely nothing by default because no action needs to be
taken given a passed test. Logs like Maven's are UIs, and UIs that are
cluttered with unactionable, unimportant information are hard to
understand and work with. Show the developer what the developer needs
to know, and nothing else.
On Tue, Feb 21, 2023 at 1:28 PM Piotr P. Karwasz
<[email protected]> wrote:
Hi Elliotte,
On Mon, 20 Feb 2023 at 19:51, Elliotte Rusty Harold <[email protected]> wrote:
I don't believe anyone reads most of these messages most of the time.
In fact, I'd venture that well more than 99% of them are never read by
anyone.
Some people started reading these after Log4Shell. On StackOverflow
questions like "Why is Maven downloading ...?"[1]
If I might add my 2 cents, the right amount of logging should:
1. allow people with 56 Kbps connections to understand why the build
is taking ages,
2. inform the other users (that set -ntp), what does Maven download and why.
The second case could have logs like:
Downloading plugin dependencies:
org.apache.maven.plugins:maven-compiler-plugin:3.11.0,
org.apache.maven.shared:maven.shared.utils:3.3.4, ...
Downloading compile dependencies: org.apache.logging.log4j:log4j-api:2.20.0, ...
Not sure if this should be at INFO or DEBUG level: during a CI build
this info is important to understand whether a fresh snapshot was
downloaded from a remote repo or the one installed locally (e.g. in
the previous step) is being used.
Piotr
[1] https://stackoverflow.com/q/70473780/11748454
---------------------------------------------------------------------
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]
