Re: Thoughts on MNG-5626 and the need for a log file
Sorry I was not clear, what I was trying to say is: maven has logging built in, if you need a logfile you can pass the -l switch or re-configure slf4j. It also has some control over the loglevel (-X). Most users dont need it because they (think CI Server) just catch stdout. http://maven.apache.org/maven-logging.html Gruss Bernd Am Mon, 5 May 2014 15:14:33 -0500 schrieb Paul Benedict : > -X is debug/stack traces, right? That's great when you want a > slosh-load of debug information, but that's only useful when you're > looking for a problem. There's no recourse when problems oddball > conditions occur with -X not enabled. My point is Maven and Maven > plugins should be able to log those abnormal conditions in the course > of a normal build. We shouldn't have to dump the world -- especially > when the problem is not always repeatable. > > > > > Cheers, > Paul > > > On Mon, May 5, 2014 at 2:38 PM, Bernd Eckenfels > wrote: > > > Am Mon, 5 May 2014 14:17:50 -0500 > > schrieb Paul Benedict : > > > > > What should be logged? Warnings. I actually would propose > > > exceptions too because them on the screen only help if you have > > > "logging" like a Hudson instance to view them. > > > > Uh, what is wrong with mvn -X -l? > > > > Gruss > > Bernd > > > > - > > 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: Thoughts on MNG-5626 and the need for a log file
Sorry I was not clear, what I was trying to say is: maven has logging built in, if you need a logfile you can pass the -l switch or re-configure slf4j. It also has some control over the loglevel (-X). Most users dont need it because they (think CI Server) just catch stdout. http://maven.apache.org/maven-logging.html Gruss Bernd Am Mon, 5 May 2014 15:14:33 -0500 schrieb Paul Benedict : > -X is debug/stack traces, right? That's great when you want a > slosh-load of debug information, but that's only useful when you're > looking for a problem. There's no recourse when problems oddball > conditions occur with -X not enabled. My point is Maven and Maven > plugins should be able to log those abnormal conditions in the course > of a normal build. We shouldn't have to dump the world -- especially > when the problem is not always repeatable. > > > > > Cheers, > Paul > > > On Mon, May 5, 2014 at 2:38 PM, Bernd Eckenfels > wrote: > > > Am Mon, 5 May 2014 14:17:50 -0500 > > schrieb Paul Benedict : > > > > > What should be logged? Warnings. I actually would propose > > > exceptions too because them on the screen only help if you have > > > "logging" like a Hudson instance to view them. > > > > Uh, what is wrong with mvn -X -l? > > > > Gruss > > Bernd > > > > - > > 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: Thoughts on MNG-5626 and the need for a log file
-X is debug/stack traces, right? That's great when you want a slosh-load of debug information, but that's only useful when you're looking for a problem. There's no recourse when problems oddball conditions occur with -X not enabled. My point is Maven and Maven plugins should be able to log those abnormal conditions in the course of a normal build. We shouldn't have to dump the world -- especially when the problem is not always repeatable. Cheers, Paul On Mon, May 5, 2014 at 2:38 PM, Bernd Eckenfels wrote: > Am Mon, 5 May 2014 14:17:50 -0500 > schrieb Paul Benedict : > > > What should be logged? Warnings. I actually would propose exceptions > > too because them on the screen only help if you have "logging" like a > > Hudson instance to view them. > > Uh, what is wrong with mvn -X -l? > > Gruss > Bernd > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Thoughts on MNG-5626 and the need for a log file
Am Mon, 5 May 2014 14:17:50 -0500 schrieb Paul Benedict : > What should be logged? Warnings. I actually would propose exceptions > too because them on the screen only help if you have "logging" like a > Hudson instance to view them. Uh, what is wrong with mvn -X -l? Gruss Bernd - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-5626 and the need for a log file
In the instance of MNG-5256, the log file could dump the values that go into calculating a negative build time. I think that would be very insightful to trace the root cause. What should be logged? Warnings. I actually would propose exceptions too because them on the screen only help if you have "logging" like a Hudson instance to view them. Paul Cheers, Paul On Mon, May 5, 2014 at 1:49 PM, Michael Osipov wrote: > Am 2014-05-05 16:20, schrieb Paul Benedict: > > One thing that I like about Eclipse is that it contains a log file to >> capture the unexpected warning or error. These warnings or errors may not >> kill the program but at least I can peer inside to see what's going on. >> >> With regard to MNG-5626, it makes me wonder should Maven have a default >> logging location. There are situations that shouldn't kill a build (like >> negative build times) but are extraordinary enough that they should be >> dumped to a log file for studying. I think plugins should have the ability >> to do such things for the sake of diagnosing out unfavorable >> conditions/bugs in the code. >> >> BTW, this is a different feature than debug info and stack traces. I don't >> want to bug the user with more on their screen. I just want normal builds >> to run like they do except introduce a warning log. >> > > Paul, > > how would a log file help to solve the above mentioned problem (MNG-5626). > I guess Logback relies on currentMillis too. > > Moreover, what should be logged and to what extent? > > I do think, it's worth investigating but quite hard to decide what should > be printed to such a file. Using SLF4J markers and a distinct Logback > configuration may be a good help. > > Michael > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Thoughts on MNG-5626 and the need for a log file
Am 2014-05-05 16:20, schrieb Paul Benedict: One thing that I like about Eclipse is that it contains a log file to capture the unexpected warning or error. These warnings or errors may not kill the program but at least I can peer inside to see what's going on. With regard to MNG-5626, it makes me wonder should Maven have a default logging location. There are situations that shouldn't kill a build (like negative build times) but are extraordinary enough that they should be dumped to a log file for studying. I think plugins should have the ability to do such things for the sake of diagnosing out unfavorable conditions/bugs in the code. BTW, this is a different feature than debug info and stack traces. I don't want to bug the user with more on their screen. I just want normal builds to run like they do except introduce a warning log. Paul, how would a log file help to solve the above mentioned problem (MNG-5626). I guess Logback relies on currentMillis too. Moreover, what should be logged and to what extent? I do think, it's worth investigating but quite hard to decide what should be printed to such a file. Using SLF4J markers and a distinct Logback configuration may be a good help. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Thoughts on MNG-5626 and the need for a log file
One thing that I like about Eclipse is that it contains a log file to capture the unexpected warning or error. These warnings or errors may not kill the program but at least I can peer inside to see what's going on. With regard to MNG-5626, it makes me wonder should Maven have a default logging location. There are situations that shouldn't kill a build (like negative build times) but are extraordinary enough that they should be dumped to a log file for studying. I think plugins should have the ability to do such things for the sake of diagnosing out unfavorable conditions/bugs in the code. BTW, this is a different feature than debug info and stack traces. I don't want to bug the user with more on their screen. I just want normal builds to run like they do except introduce a warning log. Thoughts? Cheers, Paul
