+1 logback > Am 23.02.2023 um 06:39 schrieb Guillaume Nodet <gno...@apache.org>: > > Maven Daemon uses logback instead of the simple logger. This definitely > allows more configuration freedom. > Should we switch maven 4 to logback or log4j too ? > > Le mer. 22 févr. 2023 à 18:45, Ralph Goers <ralph.go...@dslextreme.com> a > écrit : > >> 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 >> >> > > -- > ------------------------ > Guillaume Nodet
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
