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?
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. 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 > > > > >
