Re: And while I'm on the subject of logging

[Romain Manni-Bucau]

Le ven. 24 févr. 2023 à 17:31, Delany  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 
> 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  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | 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
> > > >  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-m

Re: And while I'm on the subject of logging

[Delany]

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 
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  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | 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
> > >  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
> >
> >
>

Re: And while I'm on the subject of logging

[Xeno Amess]

+1 for -e default

From: Romain Manni-Bucau 
Sent: Friday, February 24, 2023 9:15:15 PM
To: Maven Developers List 
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 
a écrit :

> Hi Elliot,
>
> did you try to use mvnDebug?
>
> > Am 24.02.2023 um 13:26 schrieb Elliotte Rusty Harold  >:
> >
> > 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
> >  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
>
>

Re: And while I'm on the subject of logging

[Romain Manni-Bucau]

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 24 févr. 2023 à 13:33, Kemal Soysal 
a écrit :

> Hi Elliot,
>
> did you try to use mvnDebug?
>
> > Am 24.02.2023 um 13:26 schrieb Elliotte Rusty Harold  >:
> >
> > 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
> >  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
>
>

Re: And while I'm on the subject of logging

[Kemal Soysal]

Hi Elliot,

did you try to use mvnDebug?

> Am 24.02.2023 um 13:26 schrieb Elliotte Rusty Harold :
> 
> 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
>  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

Re: And while I'm on the subject of logging

[Elliotte Rusty Harold]

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

Re: And while I'm on the subject of logging

[Delany]

In the spirit of your elephant analogy, what is deserving of INFO level
logging?


On Thu, 23 Feb 2023 at 14:11, Elliotte Rusty Harold 
wrote:

> On Wed, Feb 22, 2023 at 11:51 AM Romain Manni-Bucau
>  wrote:
> >
> > 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.
>
> Thanks for saying this. I think I see the disconnect now. I'm saying
> log the errors and identify what's an error and what isn't. Artifact
> is 404? Log it. Artifact is slow? Log it. Artifact downloads just
> fine: don't log it. Don't hide the real problems in a sea of useless
> log junk.
>
> > 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.
>
> Again, that is *NOT* what I am saying. I think that network issues are
> a real problem which is why I want them to be much easier to find and
> debug by not logging things that aren't problems.
>
> --
> 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
>
>

Re: And while I'm on the subject of logging

[Romain Manni-Bucau]

Hmm, I see but it also means you will hide the network issues because they
often are "you will not see anything".
Does it bother you so often? I mean, most of the time it is downloaded.
Is it just a snapshot thing? Maybe we can reduce the log only for snapshot
daily (whatever frequency) updates?


Le jeu. 23 févr. 2023 à 13:11, Elliotte Rusty Harold  a
écrit :

> On Wed, Feb 22, 2023 at 11:51 AM Romain Manni-Bucau
>  wrote:
> >
> > 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.
>
> Thanks for saying this. I think I see the disconnect now. I'm saying
> log the errors and identify what's an error and what isn't. Artifact
> is 404? Log it. Artifact is slow? Log it. Artifact downloads just
> fine: don't log it. Don't hide the real problems in a sea of useless
> log junk.
>
> > 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.
>
> Again, that is *NOT* what I am saying. I think that network issues are
> a real problem which is why I want them to be much easier to find and
> debug by not logging things that aren't problems.
>
> --
> 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
>
>

Re: And while I'm on the subject of logging

[Elliotte Rusty Harold]

On Wed, Feb 22, 2023 at 11:51 AM Romain Manni-Bucau
 wrote:
>
> 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.

Thanks for saying this. I think I see the disconnect now. I'm saying
log the errors and identify what's an error and what isn't. Artifact
is 404? Log it. Artifact is slow? Log it. Artifact downloads just
fine: don't log it. Don't hide the real problems in a sea of useless
log junk.

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

Again, that is *NOT* what I am saying. I think that network issues are
a real problem which is why I want them to be much easier to find and
debug by not logging things that aren't problems.

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

Re: And while I'm on the subject of logging

[Xeno Amess]

you can add a config or parameter to do this.
BUT I need that log, please don't remove it

From: Kemal Soysal 
Sent: Thursday, February 23, 2023 5:39:08 PM
To: Maven Developers List 
Subject: Re: And while I'm on the subject of logging

+1 logback

> Am 23.02.2023 um 06:39 schrieb Guillaume Nodet :
>
> Maven Daemon uses logback instead of the simple logger.  This definitely
> allows more configuration freedom.
> Should we switch maven 4 to logback or log4j too ?
>
> Le mer. 22 févr. 2023 à 18:45, Ralph Goers  a
> écrit :
>
>> Might I suggest that you are never going to make everyone happy.  That is
>> why Logging frameworks such as Log4j support using Logger names, Log
>> Levels, and Markers as basic ways of categorizing log events. With those
>> you can continue to log events but filter them down to just what the user
>> wants.
>>
>> Unfortunately, doing this will tie you to a logging implementation if you
>> try to do it programmatically.  If you let the user supply (or override)
>> the logging configuration then this wouldn’t be an issue.
>>
>> Ralph
>>
>>> On Feb 22, 2023, at 5:54 AM, Romain Manni-Bucau 
>> wrote:
>>>
>>> +1 to Guillaume proposal for default behavior while -X still logs
>>> everything (in logs ;))
>>>
>>> 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 à 13:33, Gary Gregory  a
>>> écrit :
>>>
>>>> This echoes IMO what a higher level app (Maven in this case) should do,
>>>> tell me when something unusual happens, like when something is taking a
>>>> long time. For us Windows users, the Explorer UI only pops up its
>> progress
>>>> dialog when you are copying "a lot" or its taking "a long time",
>> otherwise
>>>> it is quiet.
>>>>
>>>> Question: when I ask mvn for -U behavior, I do like to see the download
>>>> logging, because I am asking for non-default behavior, I expect the
>> extra
>>>> output.
>>>>
>>>> As previously mentioned, there won't be change that makes everyone
>> happy,
>>>> but IMO, there should be values I can put in MAVEN_ARGS to make 80% of
>>>> folks happy.
>>>>
>>>> Gary
>>>>
>>>> On Wed, Feb 22, 2023, 06:56 Guillaume Nodet  wrote:
>>>>
>>>>> 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 <
>> rmannibu...@gmail.com
>>>>>
>>>>> 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
>>

Re: And while I'm on the subject of logging

[Kemal Soysal]

+1 logback

> Am 23.02.2023 um 06:39 schrieb Guillaume Nodet :
> 
> Maven Daemon uses logback instead of the simple logger.  This definitely
> allows more configuration freedom.
> Should we switch maven 4 to logback or log4j too ?
> 
> Le mer. 22 févr. 2023 à 18:45, Ralph Goers  a
> écrit :
> 
>> Might I suggest that you are never going to make everyone happy.  That is
>> why Logging frameworks such as Log4j support using Logger names, Log
>> Levels, and Markers as basic ways of categorizing log events. With those
>> you can continue to log events but filter them down to just what the user
>> wants.
>> 
>> Unfortunately, doing this will tie you to a logging implementation if you
>> try to do it programmatically.  If you let the user supply (or override)
>> the logging configuration then this wouldn’t be an issue.
>> 
>> Ralph
>> 
>>> On Feb 22, 2023, at 5:54 AM, Romain Manni-Bucau 
>> wrote:
>>> 
>>> +1 to Guillaume proposal for default behavior while -X still logs
>>> everything (in logs ;))
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github <
>> https://github.com/rmannibucau> |
>>> LinkedIn  | Book
>>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>>> 
>>> 
>>> Le mer. 22 févr. 2023 à 13:33, Gary Gregory  a
>>> écrit :
>>> 
 This echoes IMO what a higher level app (Maven in this case) should do,
 tell me when something unusual happens, like when something is taking a
 long time. For us Windows users, the Explorer UI only pops up its
>> progress
 dialog when you are copying "a lot" or its taking "a long time",
>> otherwise
 it is quiet.
 
 Question: when I ask mvn for -U behavior, I do like to see the download
 logging, because I am asking for non-default behavior, I expect the
>> extra
 output.
 
 As previously mentioned, there won't be change that makes everyone
>> happy,
 but IMO, there should be values I can put in MAVEN_ARGS to make 80% of
 folks happy.
 
 Gary
 
 On Wed, Feb 22, 2023, 06:56 Guillaume Nodet  wrote:
 
> 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 <
>> rmannibu...@gmail.com
> 
> 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  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
>> 
> 
 
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>> 
>> 
>> Le mer. 22 févr. 2023 à 12:40, Elliotte Rusty Harold <
 elh...@ibiblio.org
>> 
>> a
>> écrit :
>> 
>>> On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
>>>  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 t

Re: And while I'm on the subject of logging

[Romain Manni-Bucau]

-1 to switch to logback or log4j (in particular v2 which is still slow and
fatty).
Think what we need is a good system prop config, can be achieved with jul
(ex: https://www.yupiik.io/yupiik-logging/jul-integration.html).
What I like with mvnd is not logback but the jansi/terminal usage which
helps to keep active tasks shown.

Le jeu. 23 févr. 2023 à 08:08, Paul Hammant  a
écrit :

> I wrote much of
>
> https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=118163392#content/view/118163392
> 20 years back, and still stand by the basic message.
>
> Maven is a build tool though, and aims and reproducibility. Minimal output
> should be the default (console and log files). If someone wants more, they
> can run the build again with another —argument. Cough, I mean -Dargument
>

Re: And while I'm on the subject of logging

[Paul Hammant]

I wrote much of
https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=118163392#content/view/118163392
20 years back, and still stand by the basic message.

Maven is a build tool though, and aims and reproducibility. Minimal output
should be the default (console and log files). If someone wants more, they
can run the build again with another —argument. Cough, I mean -Dargument

Re: And while I'm on the subject of logging

[Guillaume Nodet]

Maven Daemon uses logback instead of the simple logger.  This definitely
allows more configuration freedom.
Should we switch maven 4 to logback or log4j too ?

Le mer. 22 févr. 2023 à 18:45, Ralph Goers  a
écrit :

> Might I suggest that you are never going to make everyone happy.  That is
> why Logging frameworks such as Log4j support using Logger names, Log
> Levels, and Markers as basic ways of categorizing log events. With those
> you can continue to log events but filter them down to just what the user
> wants.
>
> Unfortunately, doing this will tie you to a logging implementation if you
> try to do it programmatically.  If you let the user supply (or override)
> the logging configuration then this wouldn’t be an issue.
>
> Ralph
>
> > On Feb 22, 2023, at 5:54 AM, Romain Manni-Bucau 
> wrote:
> >
> > +1 to Guillaume proposal for default behavior while -X still logs
> > everything (in logs ;))
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 22 févr. 2023 à 13:33, Gary Gregory  a
> > écrit :
> >
> >> This echoes IMO what a higher level app (Maven in this case) should do,
> >> tell me when something unusual happens, like when something is taking a
> >> long time. For us Windows users, the Explorer UI only pops up its
> progress
> >> dialog when you are copying "a lot" or its taking "a long time",
> otherwise
> >> it is quiet.
> >>
> >> Question: when I ask mvn for -U behavior, I do like to see the download
> >> logging, because I am asking for non-default behavior, I expect the
> extra
> >> output.
> >>
> >> As previously mentioned, there won't be change that makes everyone
> happy,
> >> but IMO, there should be values I can put in MAVEN_ARGS to make 80% of
> >> folks happy.
> >>
> >> Gary
> >>
> >> On Wed, Feb 22, 2023, 06:56 Guillaume Nodet  wrote:
> >>
> >>> 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 <
> rmannibu...@gmail.com
> >>>
> >>> 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  |  Blog
>   | Old Blog
>   | Github <
>  https://github.com/rmannibucau> |
>  LinkedIn  | Book
>  <
> 
> >>>
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> 
> 
>  Le mer. 22 févr. 2023 à 12:40, Elliotte Rusty Harold <
> >> elh...@ibiblio.org
> 
>  a
>  écrit :
> 
> > On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
> >  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 co

Re: And while I'm on the subject of logging

[Ralph Goers]

Might I suggest that you are never going to make everyone happy.  That is why 
Logging frameworks such as Log4j support using Logger names, Log Levels, and 
Markers as basic ways of categorizing log events. With those you can continue 
to log events but filter them down to just what the user wants. 

Unfortunately, doing this will tie you to a logging implementation if you try 
to do it programmatically.  If you let the user supply (or override) the 
logging configuration then this wouldn’t be an issue.

Ralph

> On Feb 22, 2023, at 5:54 AM, Romain Manni-Bucau  wrote:
> 
> +1 to Guillaume proposal for default behavior while -X still logs
> everything (in logs ;))
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le mer. 22 févr. 2023 à 13:33, Gary Gregory  a
> écrit :
> 
>> This echoes IMO what a higher level app (Maven in this case) should do,
>> tell me when something unusual happens, like when something is taking a
>> long time. For us Windows users, the Explorer UI only pops up its progress
>> dialog when you are copying "a lot" or its taking "a long time", otherwise
>> it is quiet.
>> 
>> Question: when I ask mvn for -U behavior, I do like to see the download
>> logging, because I am asking for non-default behavior, I expect the extra
>> output.
>> 
>> As previously mentioned, there won't be change that makes everyone happy,
>> but IMO, there should be values I can put in MAVEN_ARGS to make 80% of
>> folks happy.
>> 
>> Gary
>> 
>> On Wed, Feb 22, 2023, 06:56 Guillaume Nodet  wrote:
>> 
>>> 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 >> 
>>> 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  |  Blog
  | Old Blog
  | Github <
 https://github.com/rmannibucau> |
 LinkedIn  | Book
 <
 
>>> 
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
> 
 
 
 Le mer. 22 févr. 2023 à 12:40, Elliotte Rusty Harold <
>> elh...@ibiblio.org
 
 a
 écrit :
 
> On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
>  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 w

Re: And while I'm on the subject of logging

[Romain Manni-Bucau]

+1 to Guillaume proposal for default behavior while -X still logs
everything (in logs ;))

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 22 févr. 2023 à 13:33, Gary Gregory  a
écrit :

> This echoes IMO what a higher level app (Maven in this case) should do,
> tell me when something unusual happens, like when something is taking a
> long time. For us Windows users, the Explorer UI only pops up its progress
> dialog when you are copying "a lot" or its taking "a long time", otherwise
> it is quiet.
>
> Question: when I ask mvn for -U behavior, I do like to see the download
> logging, because I am asking for non-default behavior, I expect the extra
> output.
>
> As previously mentioned, there won't be change that makes everyone happy,
> but IMO, there should be values I can put in MAVEN_ARGS to make 80% of
> folks happy.
>
> Gary
>
> On Wed, Feb 22, 2023, 06:56 Guillaume Nodet  wrote:
>
> > 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  >
> > 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  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le mer. 22 févr. 2023 à 12:40, Elliotte Rusty Harold <
> elh...@ibiblio.org
> > >
> > > a
> > > écrit :
> > >
> > > > On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
> > > >  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
> > > > elh...@ibiblio.org
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > 
> > Guillaume Nodet
> >
>

Re: And while I'm on the subject of logging

[Gary Gregory]

This echoes IMO what a higher level app (Maven in this case) should do,
tell me when something unusual happens, like when something is taking a
long time. For us Windows users, the Explorer UI only pops up its progress
dialog when you are copying "a lot" or its taking "a long time", otherwise
it is quiet.

Question: when I ask mvn for -U behavior, I do like to see the download
logging, because I am asking for non-default behavior, I expect the extra
output.

As previously mentioned, there won't be change that makes everyone happy,
but IMO, there should be values I can put in MAVEN_ARGS to make 80% of
folks happy.

Gary

On Wed, Feb 22, 2023, 06:56 Guillaume Nodet  wrote:

> 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 
> 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  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 22 févr. 2023 à 12:40, Elliotte Rusty Harold  >
> > a
> > écrit :
> >
> > > On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
> > >  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
> > > elh...@ibiblio.org
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
>
> --
> 
> Guillaume Nodet
>

Re: And while I'm on the subject of logging

[Delany]

Another example of excessive logging prompting one to find the root cause:

On Mon, 6 Feb 2023 at 15:03, James Agnew  wrote:

> Just to close the loop in case anyone finds this post.
>
> I had discounted the idea that a version range was the cause because I went
> over all of the POMs in my project and was sure none of them had a range
> version. I ended up attaching a debugger to Maven to try and figure out why
> it was doing all of this resolving and discovering... one of the libraries
> I had as a dependency in one of my modules had a range for the same
> dependency that I was importing with a specific version in my own module.
>
>
>
> On Fri, Jan 27, 2023 at 7:47 PM Łukasz Dywicki 
> wrote:
>
> > Hello James,
> > You can configure snapshot repository to have custom update interval.
> > However from your mail I can smell some version range being used as
> > Maven would normally go only to remote repos to check is there a new
> > build of 6.3.14-SNAPSHOT of hapi-fhir-base. If you see
> > 6.1.0-PRE1-SNAPSHOT its most likely being checked because of a range
> > which is defined for hapi-fhir-base, one of its dependencies or other
> > dependencies you list in your project.
> >
> > To reduce amount of repository round trips please have a look on Maven
> > settings reference:
> > https://maven.apache.org/settings.html#Repositories
> >
> > Option you may look at is updatePolicy which can be specified inside
> >  element. There are several values available. For example
> > always, daily, never, interval:X (where X stands for minutes).
> > Switching to inverval:24 might prevent you from seeing update check
> > after midnight, but you will have it at the start of every day!
> >
> > Hope that it helps you . ;-)
> > Łukasz
> > --
> > http://code-house.org
> > PS. Thank you for a great library!
> >
> > On 27.01.2023 22:47, James Agnew wrote:
> > > I'm wondering if this is something others have seen and perhaps
> something
> > > I'm doing wrong.
> > >
> > > I have a Maven project that uses a SNAPSHOT version of a library. I
> know
> > > Maven needs to check the maven-metadata.xml file every day in order to
> > > check if a new version of the snapshot is available, but in my case it
> > > seems to be downloading this file for every version of the snapshot
> that
> > > ever existed.
> > >
> > > My pom.xml references the dependency ca.uhn.hapi.fhir:hapi-fhir-base
> with
> > > 6.3.14-SNAPSHOT, but in my build logs I see lines
> such
> > > as:
> > >
> > > 16:34:58.543 INFO Downloading from oss-snapshots:
> > >
> >
> https://oss.sonatype.org/content/repositories/snapshots/ca/uhn/hapi/fhir/hapi-fhir/6.1.0-PRE1-SNAPSHOT/maven-metadata.xml
> > > 16:36:29.663 INFO Downloading from oss-snapshots:
> > >
> >
> https://oss.sonatype.org/content/repositories/snapshots/ca/uhn/hapi/fhir/hapi-fhir-base/6.1.0-PRE2-SNAPSHOT/maven-metadata.xml
> > > 16:36:34.835 INFO Downloading from oss-snapshots:
> > >
> >
> https://oss.sonatype.org/content/repositories/snapshots/ca/uhn/hapi/fhir/hapi-fhir-base/6.1.0-PRE3-SNAPSHOT/maven-metadata.xml
> > >
> > > ..and many more. Downloading all of these versions for all of the
> modules
> > > in this library is adding tons of time and noise to my build. Is there
> a
> > > way to configure Maven to not do this?
> > >
> > > Cheers,
> > > James
> > >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: And while I'm on the subject of logging

[Delany]

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

> On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
>  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
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: And while I'm on the subject of logging

[Kemal Soysal]

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 -, 
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 :
> 
> 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  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  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>> 
>> 
>> Le mer. 22 févr. 2023 à 12:40, Elliotte Rusty Harold 
>> a
>> écrit :
>> 
>>> On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
>>>  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
>>> elh...@ibiblio.org
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>> 
>>> 
>> 
> 
> 
> -- 
> 
> Guillaume Nodet


--
Kemal Soysal


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: And while I'm on the subject of logging

[Guillaume Nodet]

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  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  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 22 févr. 2023 à 12:40, Elliotte Rusty Harold 
> a
> écrit :
>
> > On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
> >  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
> > elh...@ibiblio.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>


-- 

Guillaume Nodet

Re: And while I'm on the subject of logging

[Romain Manni-Bucau]

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 22 févr. 2023 à 12:40, Elliotte Rusty Harold  a
écrit :

> On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
>  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
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: And while I'm on the subject of logging

[Elliotte Rusty Harold]

On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
 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
elh...@ibiblio.org

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: And while I'm on the subject of logging

[Romain Manni-Bucau]

Le mar. 21 févr. 2023 à 21:16, Elliotte Rusty Harold  a
écrit :

> On Tue, Feb 21, 2023 at 3:07 PM Romain Manni-Bucau
>  wrote:
>
> > In terms of default I think default should match the most common case and
> > downloads is not a common case for maven but a very troublesome one when
> it
> > fails or hangs and not logging anything means maven hangs for end user
> > without idea why until you kill -3 it which is often hard on CI so think
> > "downloading" info is key there, similarly "downloaded" enables to know
> an
> > artifact and from where is used in classpath(s) which is key for the same
> > reason.
>
> Logging is **not** a solution for this problem. It is a band-aid, and
> a poor one. Maven itself should not hang. Instead Maven should
> explicitly fail and log a detailed error message when a download
> fails. That is, it should report the actual problem. It should not
> report 999 things that happened before the problem and expect the user
> infer what the problem is, like trying to get someone to imagine an
> ele[hant in a room by describing everything in the room that is not an
> elephant and asking them to notice the elephant shaped hole in the
> description.
>


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.

The elephant metaphore works if you add "when the elephant is there" which
is rare so ok.

Think you chase a misconfig of CI/machine issue more than a maven issue.


> If Maven indeed fails to recognize and report a failed or hung
> download, please file a bug in Jira.
>
> --
> 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
>
>

Re: And while I'm on the subject of logging

[Elliotte Rusty Harold]

On Tue, Feb 21, 2023 at 3:07 PM Romain Manni-Bucau
 wrote:

> In terms of default I think default should match the most common case and
> downloads is not a common case for maven but a very troublesome one when it
> fails or hangs and not logging anything means maven hangs for end user
> without idea why until you kill -3 it which is often hard on CI so think
> "downloading" info is key there, similarly "downloaded" enables to know an
> artifact and from where is used in classpath(s) which is key for the same
> reason.

Logging is **not** a solution for this problem. It is a band-aid, and
a poor one. Maven itself should not hang. Instead Maven should
explicitly fail and log a detailed error message when a download
fails. That is, it should report the actual problem. It should not
report 999 things that happened before the problem and expect the user
infer what the problem is, like trying to get someone to imagine an
ele[hant in a room by describing everything in the room that is not an
elephant and asking them to notice the elephant shaped hole in the
description.

If Maven indeed fails to recognize and report a failed or hung
download, please file a bug in Jira.

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

Re: And while I'm on the subject of logging

[Romain Manni-Bucau]

What I dislike with -vvv or --log-level=[debug|info|...] is your control is
basically all or nothing (maven -q/-X, podman, curl i'm looking at your
shortcuts ;)) whereas being able to configure log level per logger name on
the CLI (ideally with completion) enables you to configure exactly what you
need and relevant.

In terms of default I think default should match the most common case and
downloads is not a common case for maven but a very troublesome one when it
fails or hangs and not logging anything means maven hangs for end user
without idea why until you kill -3 it which is often hard on CI so think
"downloading" info is key there, similarly "downloaded" enables to know an
artifact and from where is used in classpath(s) which is key for the same
reason.
Switching it off will not help human beings since they don't see the lines
most of the time (you don't drop your repo everyday and if you are bothered
with snapshots you -o) so it is really about machines/CI and there it is
relevant to have that info while CI is friendly - ie not travis or CI with
a limited output - IMHO.

Guess ultimately you can maybe join https://github.com/apache/maven/pull/869
.
Idea is to make the default (all) CI friendly by enabling *-B -q* but
having a toggle to disable it for other env.

So my 2 cts would be:

1. move the PR forward which seems to reach your expectation and enable to
make others happy since the revert is 1 short toggle - pby the doc to
enhance
2. ensure we can tune more easily the logging for advanced cases (simpler
logger keys are way too long and often need a file to be usable IMHO)
3. replace the System.out listener with logger*s* (one per event)
4. (optional) make the UI more interactive with a list of pending tasks at
the bottom - can be hard to keep portabe but would be more user friendly?

Hope it makes sense.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mar. 21 févr. 2023 à 20:14, Christoph Läubrich  a
écrit :

> A common way to control "verbosity" in commandline application is having:
>
> default : as silent as possible
> -v : show some level of output (e.g. "Downloading dependencies ...")
> -vv   : show more (e.g. Start downloading / stop downloading)
> -vvv  : even more
>
> This could easily adopted for other areas of maven, e.g.
>
> [INFO] --- maven-compiler-plugin:3.10.1:testCompile
> (default-testCompile) @ tycho-source-plugin ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 2 source files to
> /home/christoph/git/laeubi/tycho/tycho-source-plugin/target/test-classes
>
> [INFO] --- maven-jar-plugin:3.3.0:jar (default-jar) @
> tycho-sourceref-jgit ---
> [INFO] Building jar:
>
> /home/christoph/git/laeubi/tycho/tycho-extras/tycho-sourceref-jgit/target/tycho-sourceref-jgit-4.0.0-SNAPSHOT.jar
>
> [INFO] --- maven-surefire-plugin:3.0.0-M9:test (default-test) @
> tycho-sourceref-jgit ---
> [INFO] Tests are skipped.
>
> [INFO] --- maven-plugin-plugin:3.7.1:descriptor (default-descriptor) @
> tycho-source-plugin ---
> [INFO] Using 'UTF-8' encoding to read mojo source files.
>
>
> all these extra messages can be suppressed most of the time.
>
>
> So a default maven run with lowest verbosity message maybe even just
> print the following:
>
> Building my.project:module1:123 ...
> Building my.project:module2:345 ...
> Building my.project:module3:345 ...
> Build success!
>
>
>
>
>
> Am 21.02.23 um 19:59 schrieb Elliotte Rusty Harold:
> > A general pattern I notice in discussions of excessive logging — not
> > just here and not only involving Maven — is to describe a scenario in
> > which a certain log message is useful. This is not hard to do but does
> > not justify the log message. Instead it is necessary to estimate how
> > often that log message will be read and acted on. Any log message that
> > is likely to be acted on less than 1% of the time (often a lot less)
> > should not be turned on by default. It does far more harm by hiding
> > real problems than it does by once in a blue moon giving someone
> > useful info.
> >
> > The only log messages that should be shown to the developer by default
> > are ones that are expected to be acted on. For instance, a failed
> > assert in a unit test should be logged because the whole point of
> > running a unit test is to fix failures. However a passed assertion
> > should log absolutely nothing by default because no action needs to be
> > taken given a passed test. Logs like Maven's are UIs, and UIs that are
> > cluttered with unactionable, unimportant information are hard to
> > understand and work with. Show the developer what the developer needs
> > to know, and nothing else.
> >
> > On Tue, Feb 21, 2023 at 1:28 PM Piotr P. Karwasz
> >  wrote

Re: And while I'm on the subject of logging

[Christoph Läubrich]

A common way to control "verbosity" in commandline application is having:

default : as silent as possible
-v : show some level of output (e.g. "Downloading dependencies ...")
-vv   : show more (e.g. Start downloading / stop downloading)
-vvv  : even more

This could easily adopted for other areas of maven, e.g.

[INFO] --- maven-compiler-plugin:3.10.1:testCompile 
(default-testCompile) @ tycho-source-plugin ---

[INFO] Changes detected - recompiling the module!
[INFO] Compiling 2 source files to 
/home/christoph/git/laeubi/tycho/tycho-source-plugin/target/test-classes


[INFO] --- maven-jar-plugin:3.3.0:jar (default-jar) @ 
tycho-sourceref-jgit ---
[INFO] Building jar: 
/home/christoph/git/laeubi/tycho/tycho-extras/tycho-sourceref-jgit/target/tycho-sourceref-jgit-4.0.0-SNAPSHOT.jar


[INFO] --- maven-surefire-plugin:3.0.0-M9:test (default-test) @ 
tycho-sourceref-jgit ---

[INFO] Tests are skipped.

[INFO] --- maven-plugin-plugin:3.7.1:descriptor (default-descriptor) @ 
tycho-source-plugin ---

[INFO] Using 'UTF-8' encoding to read mojo source files.


all these extra messages can be suppressed most of the time.


So a default maven run with lowest verbosity message maybe even just 
print the following:


Building my.project:module1:123 ...
Building my.project:module2:345 ...
Building my.project:module3:345 ...
Build success!





Am 21.02.23 um 19:59 schrieb Elliotte Rusty Harold:

A general pattern I notice in discussions of excessive logging — not
just here and not only involving Maven — is to describe a scenario in
which a certain log message is useful. This is not hard to do but does
not justify the log message. Instead it is necessary to estimate how
often that log message will be read and acted on. Any log message that
is likely to be acted on less than 1% of the time (often a lot less)
should not be turned on by default. It does far more harm by hiding
real problems than it does by once in a blue moon giving someone
useful info.

The only log messages that should be shown to the developer by default
are ones that are expected to be acted on. For instance, a failed
assert in a unit test should be logged because the whole point of
running a unit test is to fix failures. However a passed assertion
should log absolutely nothing by default because no action needs to be
taken given a passed test. Logs like Maven's are UIs, and UIs that are
cluttered with unactionable, unimportant information are hard to
understand and work with. Show the developer what the developer needs
to know, and nothing else.

On Tue, Feb 21, 2023 at 1:28 PM Piotr P. Karwasz
 wrote:


Hi Elliotte,

On Mon, 20 Feb 2023 at 19:51, Elliotte Rusty Harold  wrote:

I don't believe anyone reads most of these messages most of the time.
In fact, I'd venture that well more than 99% of them are never read by
anyone.


Some people started reading these after Log4Shell. On StackOverflow
questions like "Why is Maven downloading ...?"[1]

If I might add my 2 cents, the right amount of logging should:

1. allow people with 56 Kbps connections to understand why the build
is taking ages,
2. inform the other users (that set -ntp), what does Maven download and why.

The second case could have logs like:

Downloading plugin dependencies:
org.apache.maven.plugins:maven-compiler-plugin:3.11.0,
org.apache.maven.shared:maven.shared.utils:3.3.4, ...
Downloading compile dependencies: org.apache.logging.log4j:log4j-api:2.20.0, ...

Not sure if this should be at INFO or DEBUG level: during a CI build
this info is important to understand whether a fresh snapshot was
downloaded from a remote repo or the one installed locally (e.g. in
the previous step) is being used.

Piotr

[1] https://stackoverflow.com/q/70473780/11748454

-
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

Re: And while I'm on the subject of logging

[Elliotte Rusty Harold]

A general pattern I notice in discussions of excessive logging — not
just here and not only involving Maven — is to describe a scenario in
which a certain log message is useful. This is not hard to do but does
not justify the log message. Instead it is necessary to estimate how
often that log message will be read and acted on. Any log message that
is likely to be acted on less than 1% of the time (often a lot less)
should not be turned on by default. It does far more harm by hiding
real problems than it does by once in a blue moon giving someone
useful info.

The only log messages that should be shown to the developer by default
are ones that are expected to be acted on. For instance, a failed
assert in a unit test should be logged because the whole point of
running a unit test is to fix failures. However a passed assertion
should log absolutely nothing by default because no action needs to be
taken given a passed test. Logs like Maven's are UIs, and UIs that are
cluttered with unactionable, unimportant information are hard to
understand and work with. Show the developer what the developer needs
to know, and nothing else.

On Tue, Feb 21, 2023 at 1:28 PM Piotr P. Karwasz
 wrote:
>
> Hi Elliotte,
>
> On Mon, 20 Feb 2023 at 19:51, Elliotte Rusty Harold  
> wrote:
> > I don't believe anyone reads most of these messages most of the time.
> > In fact, I'd venture that well more than 99% of them are never read by
> > anyone.
>
> Some people started reading these after Log4Shell. On StackOverflow
> questions like "Why is Maven downloading ...?"[1]
>
> If I might add my 2 cents, the right amount of logging should:
>
> 1. allow people with 56 Kbps connections to understand why the build
> is taking ages,
> 2. inform the other users (that set -ntp), what does Maven download and why.
>
> The second case could have logs like:
>
> Downloading plugin dependencies:
> org.apache.maven.plugins:maven-compiler-plugin:3.11.0,
> org.apache.maven.shared:maven.shared.utils:3.3.4, ...
> Downloading compile dependencies: org.apache.logging.log4j:log4j-api:2.20.0, 
> ...
>
> Not sure if this should be at INFO or DEBUG level: during a CI build
> this info is important to understand whether a fresh snapshot was
> downloaded from a remote repo or the one installed locally (e.g. in
> the previous step) is being used.
>
> Piotr
>
> [1] https://stackoverflow.com/q/70473780/11748454
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.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

Re: And while I'm on the subject of logging

[Piotr P. Karwasz]

Hi Elliotte,

On Mon, 20 Feb 2023 at 19:51, Elliotte Rusty Harold  wrote:
> I don't believe anyone reads most of these messages most of the time.
> In fact, I'd venture that well more than 99% of them are never read by
> anyone.

Some people started reading these after Log4Shell. On StackOverflow
questions like "Why is Maven downloading ...?"[1]

If I might add my 2 cents, the right amount of logging should:

1. allow people with 56 Kbps connections to understand why the build
is taking ages,
2. inform the other users (that set -ntp), what does Maven download and why.

The second case could have logs like:

Downloading plugin dependencies:
org.apache.maven.plugins:maven-compiler-plugin:3.11.0,
org.apache.maven.shared:maven.shared.utils:3.3.4, ...
Downloading compile dependencies: org.apache.logging.log4j:log4j-api:2.20.0, ...

Not sure if this should be at INFO or DEBUG level: during a CI build
this info is important to understand whether a fresh snapshot was
downloaded from a remote repo or the one installed locally (e.g. in
the previous step) is being used.

Piotr

[1] https://stackoverflow.com/q/70473780/11748454

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: And while I'm on the subject of logging

[Delany]

I wouldn't miss a thing past line 2. Since its all ERROR I have no control

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile
(default-compile) on project error_prone_core: Compilation failure
[ERROR]
/git/error-prone/core/src/main/java/com/google/errorprone/refaster/LocalVarBinding.java:[35,40]
';' expected
[ERROR]
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the
'-e' switch
[ERROR] Re-run Maven using the '-X' switch to enable verbose output
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR]   mvn [args] -r


On Tue, 21 Feb 2023 at 01:13, Elliotte Rusty Harold 
wrote:

> On Mon, Feb 20, 2023 at 10:56 PM Romain Manni-Bucau
>  wrote:
> >
> > Do you want to make maven output only SUCCESS or FAILURE? All default
> info
> > logs are close to these download logs in practise.
> >
>
> Not always, but it should be far less verbose than it is now. It is an
> oft forgotten principle of TDD that passing tests generate no output.
> Maven fails that badly.
>
> Failures should indeed generate more output. However, the only helpful
> output is the output that points to the actual failure. Page after
> page of repetitive log junk only serves to obscure the true cause. It
> is not merely unhelpful. It actively hinders devs from finding
> problems.
>
> For example, a compile error should be reported with a clear message
> and the line, column, and file where the failure occurred. The message
> should be clear and actionable. But when I'm trying to figure out
> where a missing semicolon is, I really do not need to know every last
> artifact Maven downloaded, how big it is, and how long it took to
> download. I certainly don't need to get that information twice per
> artifact.
>
> --
> 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
>
>

Re: And while I'm on the subject of logging

[Romain Manni-Bucau]

Le mar. 21 févr. 2023 à 00:13, Elliotte Rusty Harold  a
écrit :

> On Mon, Feb 20, 2023 at 10:56 PM Romain Manni-Bucau
>  wrote:
> >
> > Do you want to make maven output only SUCCESS or FAILURE? All default
> info
> > logs are close to these download logs in practise.
> >
>
> Not always, but it should be far less verbose than it is now. It is an
> oft forgotten principle of TDD that passing tests generate no output.
> Maven fails that badly.
>


until feature is a log as in maven ;)


> Failures should indeed generate more output. However, the only helpful
> output is the output that points to the actual failure. Page after
> page of repetitive log junk only serves to obscure the true cause. It
> is not merely unhelpful. It actively hinders devs from finding
> problems.
>
> For example, a compile error should be reported with a clear message
> and the line, column, and file where the failure occurred. The message
> should be clear and actionable. But when I'm trying to figure out
> where a missing semicolon is, I really do not need to know every last
> artifact Maven downloaded, how big it is, and how long it took to
> download. I certainly don't need to get that information twice per
> artifact.
>

For a download error or an artifact error you do as much as the classpath
is key for the compiler plugin.

There is no silver bullet so depends your case and default should guide on
common errors.
Current logs helped several times, are only logged on downloads (almost
never on a well setup build) and we have flags to drop them at need so I'd
rather chase actual issues like interleaving or optimise the "ui" like mvnd
did than dropping info which has its public.
That said, if we move to loggers and use --logging-xxx cli opts we can make
it customizable with a user home default set of cli options which would
make everyone happy as everyone is with vi and a setup per person ;).



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

Re: And while I'm on the subject of logging

[Elliotte Rusty Harold]

On Mon, Feb 20, 2023 at 10:56 PM Romain Manni-Bucau
 wrote:
>
> Do you want to make maven output only SUCCESS or FAILURE? All default info
> logs are close to these download logs in practise.
>

Not always, but it should be far less verbose than it is now. It is an
oft forgotten principle of TDD that passing tests generate no output.
Maven fails that badly.

Failures should indeed generate more output. However, the only helpful
output is the output that points to the actual failure. Page after
page of repetitive log junk only serves to obscure the true cause. It
is not merely unhelpful. It actively hinders devs from finding
problems.

For example, a compile error should be reported with a clear message
and the line, column, and file where the failure occurred. The message
should be clear and actionable. But when I'm trying to figure out
where a missing semicolon is, I really do not need to know every last
artifact Maven downloaded, how big it is, and how long it took to
download. I certainly don't need to get that information twice per
artifact.

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

Re: And while I'm on the subject of logging

[Romain Manni-Bucau]

Do you want to make maven output only SUCCESS or FAILURE? All default info
logs are close to these download logs in practise.

I think they are helpful, can agree with you on "not always" but having to
debug each time is worse than having to debug once from time to time so the
trade off is not bad.

That said while "enable-able" I agree it is ok but your reasoning is to
drop all logs and just use the exit status...not sure it is user friendly
at all.

Maven is like any software, it should communicate what it does to the user
without requiring all users to know the codebase IMHO so maybe just writing
an extension autoconfiguring the logs to what fits you and be it?

Anyway moving to a logger download logs really looks required whatever is
done and the interactive output can also help for human interactions.

Le lun. 20 févr. 2023 à 22:06, Elliotte Rusty Harold  a
écrit :

> On Mon, Feb 20, 2023 at 8:19 PM Romain Manni-Bucau
>  wrote:
>
> >
> > except that if you dont have it when you need (default) you have no
> > solution
>
> In my experience, about half the time when I do need a log message it
> still isn't there. I have to use a debugger, packet inspection, or
> some other technique to figure out what's going on. Programmers are
> very, very bad at predicting which log messages are likely to be
> useful. Even if it is present, it probably won't tell me most of what
> I need to know to understand and fix the problem. Log messages are not
> that helpful in practice.
>
> The reality is devs don't need almost all log messages almost all of
> the time. In those circumstances the sensible thing to do is to turn
> them off by default and require extra steps to turn them on for the
> 0.0001% of the cases when it might be helpful.
>
> --
> 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
>
>

Re: And while I'm on the subject of logging

[Elliotte Rusty Harold]

On Mon, Feb 20, 2023 at 8:19 PM Romain Manni-Bucau
 wrote:

>
> except that if you dont have it when you need (default) you have no
> solution

In my experience, about half the time when I do need a log message it
still isn't there. I have to use a debugger, packet inspection, or
some other technique to figure out what's going on. Programmers are
very, very bad at predicting which log messages are likely to be
useful. Even if it is present, it probably won't tell me most of what
I need to know to understand and fix the problem. Log messages are not
that helpful in practice.

The reality is devs don't need almost all log messages almost all of
the time. In those circumstances the sensible thing to do is to turn
them off by default and require extra steps to turn them on for the
0.0001% of the cases when it might be helpful.

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

Re: And while I'm on the subject of logging

[Romain Manni-Bucau]

Le lun. 20 févr. 2023 à 19:51, Elliotte Rusty Harold  a
écrit :

> I don't believe anyone reads most of these messages most of the time.
> In fact, I'd venture that well more than 99% of them are never read by
> anyone. The default values should serve the common use case, not the
> exceptions. If an artifact fails to download, by all means log that
> fact, but don't hide that message amongst the 231 other artifacts that
> downloaded without a problem. It doesn't make sense to spew megabytes
> of logs that obscure real problems simply because someone thinks they
> might need to read one of these messages sometime.
>

except that if you dont have it when you need (default) you have no
solution



> In practice when something does go wrong, I find myself in one of two
> cases with roughly equal probability. Either the log info I need is
> somewhere in a very long stream of text that is challenging to search
> through or the information I need is in fact not logged at all and I
> have to use other methods to find out what's happening. Gratuitous,
> verbose logging has very little use.
>

It is why I said we will never get a good default for all cases:

* CI: you want it verbose to grep when needed
* CI bis: you want it not verbose cause output has limitations
* Human: you want it verbose cause it behaves weird (hanging repo for ex)
* Human: you want it quiet cause you just want success/error

At the end the usage of logger helps and maybe something like mvnd output
(terminal) where pending ops would stay printed until successfully done.

But hiding is not a solution IMHO, going more dynamic mixed with loggers
sound like a potential one to me.



> On Mon, Feb 20, 2023 at 3:02 PM Romain Manni-Bucau
>  wrote:
> >
> > Hi,
> >
> > I think the value of these lines are to know a download is pending (so
> > downloading line is key more than knowing it got downloaded which means
> > everything is fine).
> > The size has a lot value (in particular on CI) because some builds will
> > download huge artifacts (not detailling to avoid trolls but I'm sure you
> > can think of some build) and seeing you download 200M multiple times can
> be
> > a warning and explain why CI is unlikely to answer faster than checking
> > your local (sometimes empty if not your project and you just help). It
> also
> > helps to understand why it takes so long.
> >
> > So think we really have 2 steps:
> >
> > 1. make it all fully configurable (guess we all want to avoid any new CLI
> > option for such a thing and just use logger and --logging-level?)
> > 2. define the default: here I think we should be iso of today state or go
> > to something like "downloading..." for the *phase* (not per artifact) and
> > nothing more if we want the default to be less verbose
> >
> > Hope it makes sense.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le lun. 20 févr. 2023 à 15:53, Christoph Läubrich 
> a
> > écrit :
> >
> > > Maybe then one would remove that logging at all, and use different
> > > "logging plugin extensions" :-)
> > >
> > > Am 20.02.23 um 15:50 schrieb Enrico Olivelli:
> > > > Sometimes it is helpful to see that kind of logging when you run on
> CI
> > > > and you are troubleshooting why the build is slow.
> > > > In that case it would be useful to log only in the case that the
> > > > download took more than X seconds or the speed was too low (then it
> > > > would become debatable the default values for the thresholds...)
> > > >
> > > > my 2 cents
> > > >
> > > > Enrico
> > > >
> > > > Il giorno lun 20 feb 2023 alle ore 15:46 Christoph Läubrich
> > > >  ha scritto:
> > > >>
> > > >> Well you can just reduce it to a single '.' who cares WHAT is
> download
> > > >> and where it is placed and from where... now put a line break after
> say
> > > >> 50 dots
> > > >>
> > > >>
> > > >> Am 20.02.23 um 15:42 schrieb Tamás Cservenák:
> > > >>> Howdy,
> > > >>>
> > > >>> completely agree, the default could be something along those lines:
> > > >>>
> > > >>> [DL] central
> > > >>>
> > >
> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> > > >>>
> > > >>> So something like
> > > >>> [DL|UP] $repoId $artifactUrl
> > > >>>
> > > >>> Full URL is handy as one can click on it in Terminal.app. But
> > > >>> redundant "Downloaded" is not. Maybe go for some emoji even? (arrow
> > > >>> down/arrow up?)
> > > >>>
> > > >>> T
> > > >>>
> > > >>> On Mon, Feb 20, 2023 at 3:34 PM Elliotte Rusty Harold <
> > > elh...@ibiblio.org>
> > > >>> wrote:
> > > >>>
> > >  Typical log message in build:
> > > 
> > >  Downloaded from central:
> > > 
> > > 
> > >
> https://repo.maven.a

Re: And while I'm on the subject of logging

[Elliotte Rusty Harold]

I don't believe anyone reads most of these messages most of the time.
In fact, I'd venture that well more than 99% of them are never read by
anyone. The default values should serve the common use case, not the
exceptions. If an artifact fails to download, by all means log that
fact, but don't hide that message amongst the 231 other artifacts that
downloaded without a problem. It doesn't make sense to spew megabytes
of logs that obscure real problems simply because someone thinks they
might need to read one of these messages sometime.

In practice when something does go wrong, I find myself in one of two
cases with roughly equal probability. Either the log info I need is
somewhere in a very long stream of text that is challenging to search
through or the information I need is in fact not logged at all and I
have to use other methods to find out what's happening. Gratuitous,
verbose logging has very little use.

On Mon, Feb 20, 2023 at 3:02 PM Romain Manni-Bucau
 wrote:
>
> Hi,
>
> I think the value of these lines are to know a download is pending (so
> downloading line is key more than knowing it got downloaded which means
> everything is fine).
> The size has a lot value (in particular on CI) because some builds will
> download huge artifacts (not detailling to avoid trolls but I'm sure you
> can think of some build) and seeing you download 200M multiple times can be
> a warning and explain why CI is unlikely to answer faster than checking
> your local (sometimes empty if not your project and you just help). It also
> helps to understand why it takes so long.
>
> So think we really have 2 steps:
>
> 1. make it all fully configurable (guess we all want to avoid any new CLI
> option for such a thing and just use logger and --logging-level?)
> 2. define the default: here I think we should be iso of today state or go
> to something like "downloading..." for the *phase* (not per artifact) and
> nothing more if we want the default to be less verbose
>
> Hope it makes sense.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
>
>
> Le lun. 20 févr. 2023 à 15:53, Christoph Läubrich  a
> écrit :
>
> > Maybe then one would remove that logging at all, and use different
> > "logging plugin extensions" :-)
> >
> > Am 20.02.23 um 15:50 schrieb Enrico Olivelli:
> > > Sometimes it is helpful to see that kind of logging when you run on CI
> > > and you are troubleshooting why the build is slow.
> > > In that case it would be useful to log only in the case that the
> > > download took more than X seconds or the speed was too low (then it
> > > would become debatable the default values for the thresholds...)
> > >
> > > my 2 cents
> > >
> > > Enrico
> > >
> > > Il giorno lun 20 feb 2023 alle ore 15:46 Christoph Läubrich
> > >  ha scritto:
> > >>
> > >> Well you can just reduce it to a single '.' who cares WHAT is download
> > >> and where it is placed and from where... now put a line break after say
> > >> 50 dots
> > >>
> > >>
> > >> Am 20.02.23 um 15:42 schrieb Tamás Cservenák:
> > >>> Howdy,
> > >>>
> > >>> completely agree, the default could be something along those lines:
> > >>>
> > >>> [DL] central
> > >>>
> > https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> > >>>
> > >>> So something like
> > >>> [DL|UP] $repoId $artifactUrl
> > >>>
> > >>> Full URL is handy as one can click on it in Terminal.app. But
> > >>> redundant "Downloaded" is not. Maybe go for some emoji even? (arrow
> > >>> down/arrow up?)
> > >>>
> > >>> T
> > >>>
> > >>> On Mon, Feb 20, 2023 at 3:34 PM 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
> > 
> >  -
> >  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >  For additional commands, e-m

Re: And while I'm on the subject of logging

[Delany]

I care to be able to see what is downloaded, and it makes sense to see when
an attempt is started and when it succeeds.
I don't care how big it is (I can find that out myself) or how fast its
pulled down (meaningless since parallel downloads).
When I don't want to see it I manipulate the simple logger properties.
Delany


On Mon, 20 Feb 2023 at 16:46, Christoph Läubrich 
wrote:

> Well you can just reduce it to a single '.' who cares WHAT is download
> and where it is placed and from where... now put a line break after say
> 50 dots
>
>
> Am 20.02.23 um 15:42 schrieb Tamás Cservenák:
> > Howdy,
> >
> > completely agree, the default could be something along those lines:
> >
> > [DL] central
> >
> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> >
> > So something like
> > [DL|UP] $repoId $artifactUrl
> >
> > Full URL is handy as one can click on it in Terminal.app. But
> > redundant "Downloaded" is not. Maybe go for some emoji even? (arrow
> > down/arrow up?)
> >
> > T
> >
> > On Mon, Feb 20, 2023 at 3:34 PM 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
> >>
> >> -
> >> 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
>
>

Re: And while I'm on the subject of logging

[Romain Manni-Bucau]

Hi,

I think the value of these lines are to know a download is pending (so
downloading line is key more than knowing it got downloaded which means
everything is fine).
The size has a lot value (in particular on CI) because some builds will
download huge artifacts (not detailling to avoid trolls but I'm sure you
can think of some build) and seeing you download 200M multiple times can be
a warning and explain why CI is unlikely to answer faster than checking
your local (sometimes empty if not your project and you just help). It also
helps to understand why it takes so long.

So think we really have 2 steps:

1. make it all fully configurable (guess we all want to avoid any new CLI
option for such a thing and just use logger and --logging-level?)
2. define the default: here I think we should be iso of today state or go
to something like "downloading..." for the *phase* (not per artifact) and
nothing more if we want the default to be less verbose

Hope it makes sense.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 20 févr. 2023 à 15:53, Christoph Läubrich  a
écrit :

> Maybe then one would remove that logging at all, and use different
> "logging plugin extensions" :-)
>
> Am 20.02.23 um 15:50 schrieb Enrico Olivelli:
> > Sometimes it is helpful to see that kind of logging when you run on CI
> > and you are troubleshooting why the build is slow.
> > In that case it would be useful to log only in the case that the
> > download took more than X seconds or the speed was too low (then it
> > would become debatable the default values for the thresholds...)
> >
> > my 2 cents
> >
> > Enrico
> >
> > Il giorno lun 20 feb 2023 alle ore 15:46 Christoph Läubrich
> >  ha scritto:
> >>
> >> Well you can just reduce it to a single '.' who cares WHAT is download
> >> and where it is placed and from where... now put a line break after say
> >> 50 dots
> >>
> >>
> >> Am 20.02.23 um 15:42 schrieb Tamás Cservenák:
> >>> Howdy,
> >>>
> >>> completely agree, the default could be something along those lines:
> >>>
> >>> [DL] central
> >>>
> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> >>>
> >>> So something like
> >>> [DL|UP] $repoId $artifactUrl
> >>>
> >>> Full URL is handy as one can click on it in Terminal.app. But
> >>> redundant "Downloaded" is not. Maybe go for some emoji even? (arrow
> >>> down/arrow up?)
> >>>
> >>> T
> >>>
> >>> On Mon, Feb 20, 2023 at 3:34 PM 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
> 
>  -
>  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
> >>
> >
> > -
> > 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
>
>

Re: And while I'm on the subject of logging

[Christoph Läubrich]

Maybe then one would remove that logging at all, and use different 
"logging plugin extensions" :-)


Am 20.02.23 um 15:50 schrieb Enrico Olivelli:

Sometimes it is helpful to see that kind of logging when you run on CI
and you are troubleshooting why the build is slow.
In that case it would be useful to log only in the case that the
download took more than X seconds or the speed was too low (then it
would become debatable the default values for the thresholds...)

my 2 cents

Enrico

Il giorno lun 20 feb 2023 alle ore 15:46 Christoph Läubrich
 ha scritto:


Well you can just reduce it to a single '.' who cares WHAT is download
and where it is placed and from where... now put a line break after say
50 dots


Am 20.02.23 um 15:42 schrieb Tamás Cservenák:

Howdy,

completely agree, the default could be something along those lines:

[DL] central
https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom

So something like
[DL|UP] $repoId $artifactUrl

Full URL is handy as one can click on it in Terminal.app. But
redundant "Downloaded" is not. Maybe go for some emoji even? (arrow
down/arrow up?)

T

On Mon, Feb 20, 2023 at 3:34 PM Elliotte Rusty Harold 
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

-
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



-
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

Re: And while I'm on the subject of logging

[Enrico Olivelli]

Sometimes it is helpful to see that kind of logging when you run on CI
and you are troubleshooting why the build is slow.
In that case it would be useful to log only in the case that the
download took more than X seconds or the speed was too low (then it
would become debatable the default values for the thresholds...)

my 2 cents

Enrico

Il giorno lun 20 feb 2023 alle ore 15:46 Christoph Läubrich
 ha scritto:
>
> Well you can just reduce it to a single '.' who cares WHAT is download
> and where it is placed and from where... now put a line break after say
> 50 dots
>
>
> Am 20.02.23 um 15:42 schrieb Tamás Cservenák:
> > Howdy,
> >
> > completely agree, the default could be something along those lines:
> >
> > [DL] central
> > https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> >
> > So something like
> > [DL|UP] $repoId $artifactUrl
> >
> > Full URL is handy as one can click on it in Terminal.app. But
> > redundant "Downloaded" is not. Maybe go for some emoji even? (arrow
> > down/arrow up?)
> >
> > T
> >
> > On Mon, Feb 20, 2023 at 3:34 PM Elliotte Rusty Harold 
> > 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
> >>
> >> -
> >> 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
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: And while I'm on the subject of logging

[Christoph Läubrich]

Well you can just reduce it to a single '.' who cares WHAT is download 
and where it is placed and from where... now put a line break after say 
50 dots



Am 20.02.23 um 15:42 schrieb Tamás Cservenák:

Howdy,

completely agree, the default could be something along those lines:

[DL] central
https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom

So something like
[DL|UP] $repoId $artifactUrl

Full URL is handy as one can click on it in Terminal.app. But
redundant "Downloaded" is not. Maybe go for some emoji even? (arrow
down/arrow up?)

T

On Mon, Feb 20, 2023 at 3:34 PM Elliotte Rusty Harold 
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

-
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

Re: And while I'm on the subject of logging

[Tamás Cservenák]

Howdy,

completely agree, the default could be something along those lines:

[DL] central
https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom

So something like
[DL|UP] $repoId $artifactUrl

Full URL is handy as one can click on it in Terminal.app. But
redundant "Downloaded" is not. Maybe go for some emoji even? (arrow
down/arrow up?)

T

On Mon, Feb 20, 2023 at 3:34 PM Elliotte Rusty Harold 
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
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

And while I'm on the subject of logging

[Elliotte Rusty Harold]

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

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org