What I dislike with -vvv or --log-level=[debug|info|...] is your control is basically all or nothing (maven -q/-X, podman, curl i'm looking at your shortcuts ;)) whereas being able to configure log level per logger name on the CLI (ideally with completion) enables you to configure exactly what you need and relevant.
In terms of default I think default should match the most common case and downloads is not a common case for maven but a very troublesome one when it fails or hangs and not logging anything means maven hangs for end user without idea why until you kill -3 it which is often hard on CI so think "downloading" info is key there, similarly "downloaded" enables to know an artifact and from where is used in classpath(s) which is key for the same reason. Switching it off will not help human beings since they don't see the lines most of the time (you don't drop your repo everyday and if you are bothered with snapshots you -o) so it is really about machines/CI and there it is relevant to have that info while CI is friendly - ie not travis or CI with a limited output - IMHO. Guess ultimately you can maybe join https://github.com/apache/maven/pull/869 . Idea is to make the default (all) CI friendly by enabling *-B -q* but having a toggle to disable it for other env. So my 2 cts would be: 1. move the PR forward which seems to reach your expectation and enable to make others happy since the revert is 1 short toggle - pby the doc to enhance 2. ensure we can tune more easily the logging for advanced cases (simpler logger keys are way too long and often need a file to be usable IMHO) 3. replace the System.out listener with logger*s* (one per event) 4. (optional) make the UI more interactive with a list of pending tasks at the bottom - can be hard to keep portabe but would be more user friendly? Hope it makes sense. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 21 févr. 2023 à 20:14, Christoph Läubrich <m...@laeubi-soft.de> a écrit : > 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 > > <piotr.karw...@gmail.com> wrote: > >> > >> Hi Elliotte, > >> > >> On Mon, 20 Feb 2023 at 19:51, Elliotte Rusty Harold <elh...@ibiblio.org> > 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: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
