+1 for -e default
________________________________
From: Romain Manni-Bucau <rmannibu...@gmail.com>
Sent: Friday, February 24, 2023 9:15:15 PM
To: Maven Developers List <dev@maven.apache.org>
Subject: Re: And while I'm on the subject of logging

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

Reply via email to