The logging discussion is well underway. According to my experience with build management, there has always been these contradicting requirements no logging to heaps of more logging in case of an error. If the build seemed to run smoothly you were fooled by everything looking fine, unless you saw the output with -X -e. Therefore our build pipeline always switched to full output. Locally for the development build we just had info.
For combining these contradictions we decided to log into a file by providing the -l <file>-<time>, so the output is saved quicker on disk for local builds and is not blocked by the terminal (specially under windows with the small output buffer and sometimes someone accidentally marking a spot that blocks the process io), and with an adjacent check script we could assure that certain unwelcome situations could be detected. From this experience… I would suggest to bring in a configurable log validator, that can be extended to specific needs, to judge the outcome of the build too. Not everything of a green build is ok. The custom validator can collect information about these problems and report them well. These are my 2 cents or less, Best Regards > Am 22.02.2023 um 12:56 schrieb Guillaume Nodet <[email protected]>: > > 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 <[email protected]> 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 <[email protected]> >> a >> écrit : >> >>> On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau >>> <[email protected]> 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 >>> [email protected] >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> > > > -- > ------------------------ > Guillaume Nodet -- Kemal Soysal --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
