Might I suggest that you are never going to make everyone happy. That is why Logging frameworks such as Log4j support using Logger names, Log Levels, and Markers as basic ways of categorizing log events. With those you can continue to log events but filter them down to just what the user wants.
Unfortunately, doing this will tie you to a logging implementation if you try to do it programmatically. If you let the user supply (or override) the logging configuration then this wouldn’t be an issue. Ralph > On Feb 22, 2023, at 5:54 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > +1 to Guillaume proposal for default behavior while -X still logs > everything (in logs ;)) > > 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 mer. 22 févr. 2023 à 13:33, Gary Gregory <garydgreg...@gmail.com> a > écrit : > >> This echoes IMO what a higher level app (Maven in this case) should do, >> tell me when something unusual happens, like when something is taking a >> long time. For us Windows users, the Explorer UI only pops up its progress >> dialog when you are copying "a lot" or its taking "a long time", otherwise >> it is quiet. >> >> Question: when I ask mvn for -U behavior, I do like to see the download >> logging, because I am asking for non-default behavior, I expect the extra >> output. >> >> As previously mentioned, there won't be change that makes everyone happy, >> but IMO, there should be values I can put in MAVEN_ARGS to make 80% of >> folks happy. >> >> Gary >> >> On Wed, Feb 22, 2023, 06:56 Guillaume Nodet <gno...@apache.org> wrote: >> >>> I do agree that logging all downloads is unneeded, and I do agree that >> the >>> hanging case can happen quite often and one needs to be informed. >>> However, both goals are not conflicting, we just need to enhance the >>> logger/downloader to: >>> * print a single statement that it starts downloading things >>> * if a download is too slow (for example, nothing has been received >> since >>> a few seconds), log a warning message >>> * log a summary when the download finished (like "Downloaded 5 >> artifacts >>> from central and yyy repositories") >>> It should not be very difficult to detect stalled downloads. >>> >>> Le mer. 22 févr. 2023 à 12:51, Romain Manni-Bucau <rmannibu...@gmail.com >>> >>> a >>> écrit : >>> >>>> Eliotte I kind of fail to follow your reasoning because it literally >>> means >>>> don't log any info and just set default log level to ERROR which I >> don't >>>> think will make anyone happy. >>>> You also tend to think everything works all the time but network issues >>> are >>>> not work/fail kind of issue, the hanging case is really bothering and >>>> downloading logs really help there when you can keep them. >>>> Lastly downloads are not expected by maven after one build so being a >> bit >>>> more verbose is not an issue and going outside the machine should >> likely >>>> always be logged at the beginning these days. >>>> >>>> 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 mer. 22 févr. 2023 à 12:40, Elliotte Rusty Harold < >> elh...@ibiblio.org >>>> >>>> a >>>> écrit : >>>> >>>>> On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau >>>>> <rmannibu...@gmail.com> wrote: >>>>>> >>>>>> >>>>>> ....except there is no issue, the download is just slow so why >> would >>>> you >>>>>> fail? >>>>>> Hapoy to discuss a better solution but logging is a very satisfying >>>> one. >>>>> >>>>> If there is no issue, don't log it. If being slow is an issue >>>>> (arguably it isn't) report it when it's slow enough to be an issue, >>>>> and only then. Too many developer tools don't finish the job by >>>>> accurately diagnosing and reporting on errors. Instead they throw up >>>>> their hands and say, "Oops. Something went wrong. Here's an >>>>> incomprehensible dump of 50% of everything that happened. Maybe the >>>>> thing that went wrong is in there somewhere. Maybe it isn't. You >>>>> figure it out." >>>>> >>>>> Imagine a compiler that instead of identifying the offending line of >>>>> syntactically incorrect code simply printed every line of source code >>>>> as it parsed it, twice. Would anyone put up with such a compiler or >>>>> would the bug reports overflow the Github issue tracker? Why do we >>>>> accept that level of error reporting in Maven downloads? >>>>> >>>>> We shouldn't force people to do what computers can easily do. One of >>>>> the things a computer can do is notice when one out of hundreds of >>>>> dependencies is causing a problem, and blame exactly that one >>>>> artifact. >>>>> >>>>> -- >>>>> Elliotte Rusty Harold >>>>> elh...@ibiblio.org >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>>> >>>> >>> >>> >>> -- >>> ------------------------ >>> Guillaume Nodet >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
