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

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 d

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

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?

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

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

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

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

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

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

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

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

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

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

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?

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

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

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

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 >

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

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

-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

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

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 so

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

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 Lo

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

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.

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

+1 to Guillaume proposal for default behavior while -X still logs everything (in logs ;)) Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn

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

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

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

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

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

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 log

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

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

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

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 *

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

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

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

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 i

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

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

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

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 id

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

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

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

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

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

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 messa

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

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 q

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

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

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

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 sho

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

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 th

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

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.

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

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 tec

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

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 a

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

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

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

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 log

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

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 bu

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

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 use

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

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 fo

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

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:

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

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

And while I'm on the subject of logging

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 ho