Le lun. 20 févr. 2023 à 19:51, Elliotte Rusty Harold <elh...@ibiblio.org> a écrit :
> 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. The default values should serve the common use case, not the > exceptions. If an artifact fails to download, by all means log that > fact, but don't hide that message amongst the 231 other artifacts that > downloaded without a problem. It doesn't make sense to spew megabytes > of logs that obscure real problems simply because someone thinks they > might need to read one of these messages sometime. > ....except that if you dont have it when you need (default) you have no solution > In practice when something does go wrong, I find myself in one of two > cases with roughly equal probability. Either the log info I need is > somewhere in a very long stream of text that is challenging to search > through or the information I need is in fact not logged at all and I > have to use other methods to find out what's happening. Gratuitous, > verbose logging has very little use. > It is why I said we will never get a good default for all cases: * CI: you want it verbose to grep when needed * CI bis: you want it not verbose cause output has limitations * Human: you want it verbose cause it behaves weird (hanging repo for ex) * Human: you want it quiet cause you just want success/error At the end the usage of logger helps and maybe something like mvnd output (terminal) where pending ops would stay printed until successfully done. But hiding is not a solution IMHO, going more dynamic mixed with loggers sound like a potential one to me. > On Mon, Feb 20, 2023 at 3:02 PM Romain Manni-Bucau > <rmannibu...@gmail.com> wrote: > > > > Hi, > > > > I think the value of these lines are to know a download is pending (so > > downloading line is key more than knowing it got downloaded which means > > everything is fine). > > The size has a lot value (in particular on CI) because some builds will > > download huge artifacts (not detailling to avoid trolls but I'm sure you > > can think of some build) and seeing you download 200M multiple times can > be > > a warning and explain why CI is unlikely to answer faster than checking > > your local (sometimes empty if not your project and you just help). It > also > > helps to understand why it takes so long. > > > > So think we really have 2 steps: > > > > 1. make it all fully configurable (guess we all want to avoid any new CLI > > option for such a thing and just use logger and --logging-level?) > > 2. define the default: here I think we should be iso of today state or go > > to something like "downloading..." for the *phase* (not per artifact) and > > nothing more if we want the default to be less verbose > > > > 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 lun. 20 févr. 2023 à 15:53, Christoph Läubrich <m...@laeubi-soft.de> > a > > écrit : > > > > > Maybe then one would remove that logging at all, and use different > > > "logging plugin extensions" :-) > > > > > > Am 20.02.23 um 15:50 schrieb Enrico Olivelli: > > > > Sometimes it is helpful to see that kind of logging when you run on > CI > > > > and you are troubleshooting why the build is slow. > > > > In that case it would be useful to log only in the case that the > > > > download took more than X seconds or the speed was too low (then it > > > > would become debatable the default values for the thresholds...) > > > > > > > > my 2 cents > > > > > > > > Enrico > > > > > > > > Il giorno lun 20 feb 2023 alle ore 15:46 Christoph Läubrich > > > > <m...@laeubi-soft.de> ha scritto: > > > >> > > > >> Well you can just reduce it to a single '.' who cares WHAT is > download > > > >> and where it is placed and from where... now put a line break after > say > > > >> 50 dots > > > >> > > > >> > > > >> Am 20.02.23 um 15:42 schrieb Tamás Cservenák: > > > >>> Howdy, > > > >>> > > > >>> completely agree, the default could be something along those lines: > > > >>> > > > >>> [DL] central > > > >>> > > > > https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom > > > >>> > > > >>> So something like > > > >>> [DL|UP] $repoId $artifactUrl > > > >>> > > > >>> Full URL is handy as one can click on it in Terminal.app. But > > > >>> redundant "Downloaded" is not. Maybe go for some emoji even? (arrow > > > >>> down/arrow up?) > > > >>> > > > >>> T > > > >>> > > > >>> On Mon, Feb 20, 2023 at 3:34 PM Elliotte Rusty Harold < > > > elh...@ibiblio.org> > > > >>> wrote: > > > >>> > > > >>>> Typical log message in build: > > > >>>> > > > >>>> Downloaded from central: > > > >>>> > > > >>>> > > > > https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom > > > >>>> (14 kB at 776 kB/s) > > > >>>> > > > >>>> I have never, ever needed or wanted to know how fast a single > artifact > > > >>>> was downloaded. And in the extremely unlikely event I cared how > big > > > >>>> it was, I'd look in .m2/repo, not a build log. Can we remove (14 > kB at > > > >>>> 776 kB/s)? > > > >>>> > > > >>>> Maven log files today are often multiple megabytes. Many > continuous > > > >>>> integration Web UIs truncate them to a 1 MB or so. Any unread > info we > > > >>>> can remove to bring the size down is helpful, and also makes it > much > > > >>>> easier for devs to find the lines they actually care about. > > > >>>> > > > >>>> -- > > > >>>> 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 > > > >>>> > > > >>>> > > > >>> > > > >> > > > >> > --------------------------------------------------------------------- > > > >> 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 > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > -- > 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 > >
