You're arguing based on principles, but my experience suggests otherwise. Some real life examples: https://issues.apache.org/jira/browse/MENFORCER-462 https://issues.apache.org/jira/browse/MNG-7214
I would not have noticed or logged either of these issues without logging. Its because they were logged that I noticed them. Since Maven is so complex, and the configuration is declarative, the only way to understand runtime execution is logging or debugging. Info-level logging has helped me understand how Maven operates. I learn next to nothing from -X logs. Another assumption you make is that only errors matter. Plenty of times my build succeeded, but it didn't produce the artifacts the way I wanted them. Diffing the logs, no matter how verbose, could show me why the output is different. But not if they're both blank. On Wed, 22 Feb 2023 at 13:40, Elliotte Rusty Harold <[email protected]> wrote: > 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] > >
