Le ven. 24 févr. 2023 à 17:31, Delany <delany.middle...@gmail.com> a écrit :
> I turned on -e as default last month and had to turn it off again. > When a change causes a group of tests to fail I get the stack trace for > each test failure first up in the project and then repeated as the cause of > the reactor failing. > I don't mind it on by default, but then how do I turn it off? > guess it needs --no-errors flag but since we switch the behavior in next major it is highly possible to change the flag IMHO > > Another point is that if you can't easily rebuild with -e on to replicate > your problem you've got a bigger problem than lots of log output. > Agree, this is why a minimum of external interactions (typically downloads) is required IMHO, otherwise really hard to see what happens. > Delany > > On Fri, 24 Feb 2023 at 15:15, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > Hi Elliotte, > > > > I agree -e should be the default, I don't see the point to not have the > > error cause when it fails. > > Your point 2 is only relevant if you never built the project nor a > project > > with the same dependencies so I guess we can assume it is a corner case > - I > > was also often checkouting projects and having to download their deps but > > it never had been an issue and actually was good to see what it uses > > without opening all the project build files IMHO so really a taste/corner > > case point. > > So at the end the aggregation report Guillaume proposed and switch -e by > > default on mvn 4 sounds like good options, no? > > > > 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 ven. 24 févr. 2023 à 13:33, Kemal Soysal < > > kemal.soy...@ls-it-solutions.de> > > a écrit : > > > > > Hi Elliot, > > > > > > did you try to use mvnDebug? > > > > > > > Am 24.02.2023 um 13:26 schrieb Elliotte Rusty Harold < > > elh...@ibiblio.org > > > >: > > > > > > > > Real world example from the non-Apache project built with Maven I'm > > > > working on this morning. > > > > > > > > 1. Build fails > > > > 2. 591 lines of log output in my console, almost all of which are > > > > artifacts being downloaded. > > > > 3. Relevant lines: 1 > > > > 4. Percentage useful content: .17% > > > > > > > > That's bad. But wait. It gets worse. > > > > > > > > The only useful output is > > > > > > > > [ERROR] Failed to execute goal XXX (default) on project XXX: > Execution > > > > default of goal XXX failed.: NullPointerException -> [Help 1] > > > > > > > > So somewhere in my code (I'm writing the plugin that failed) there's > a > > > > NullPointerException. Where? The logs don't tell me! There's no stack > > > > trace. There's no line number. The most critical information I need > to > > > > debug this isn't included by default. Of course, > > > > > > > > [ERROR] To see the full stack trace of the errors, re-run Maven with > > > > the -e switch. > > > > > > > > So I rerun with -e and there's the info I need. But > > > > > > > > 1. I shouldn't have had to rerun. The information I actually needed > > > > should have been shown to me up front. > > > > 2. I shouldn't have been bombarded with 590 lines of irrelevant log > > junk. > > > > > > > > Is anyone really willing to argue that the list of artifacts Maven > > > > downloaded and the amount of time each took are somehow more likely > to > > > > be relevant than an exception arising in the developer's own code? > And > > > > yet that is exactly what we're doing. > > > > > > > > On Mon, Feb 20, 2023 at 9:33 AM 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 > > > > > > > > > > > > > > > > -- > > > > 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 > > > > > > > > >
