My 2c: * instead of saving log messages in memory to print them to the console in case of exception, why can't the user look at the log file? I think the log file can be in 'debug' level (but make sure 'debug' messages are not actually meaningless 'trace' messages). also, analysis tools such as printing the dag, will be good. * i'm not sure how printing dots is a good solution. say i have some task that takes a long time and doesn't print anything (a compiler, copying a large file), either no dots appear - the user thinks the build is stalled, or, printing a dot periodically, in which case the task may actually be stalled and yet dots will appear. what i think is needed is a monitor of the system resources. this is commonly seen in downloading tools that tell you the rate of download. so for compilations, show the cpu usage and for copying, show the io activity. either show all indicators all the time (which i prefer), or allow each task to turn on the necessary indicator. this also solves the issue of multi-threading. * if a task is stalled,
ittay hdockter wrote: > > I'm not happy with the logging behavior of Gradle, Ant or Maven. > > I think there is too much information printed out to the console, > making it hard to figure out the important bits (for example an > unusual warning). > > I would like to improve this and have the following idea: > > A log of a successful build would look roughly like this: > > -- resources (0 sec) > -- compile (2 sec) > -- test (13 sec) > -- libs (35 sec) > -- integTest (40 sec) > Build Successful: Total time 60 sec > > We only show the task names that get executed. > > If there are log messages with a level higher than info we write them > to the console: > > -- resources (0 sec) > [warning] some message > -- compile (2 sec) > -- test (13 sec) > -- libs (35 sec) > -- integTest (40 sec) > Build Successful: Total time 60 sec > > This leaves us with three problems. > > 1.) If there is an exception, just showing the stacktrace and the > exception message is not necessarily enough to figure out the reason > for the exception. For example the ant javac task throws an exception > if the code does not compile, but this exception points to the > earlier log output to learn about the details. The solution I have in > mind would be to record all the logging. In case of an exception we > print the log of the complete build to the console. The user can > configure which log level should be recorded. The default is INFO. > > 2.) There has to be some kind of progress indicator, to inform the > user whether there is a stall and to make it more exciting to look at > the log (psychological acceleration ;) ). > I 'm not sure what is the best solution here. One solution would be > to print dots according to a certain algorithm which is based on > incoming log statements. The other solution would require more > console magic. Gradle would show only for example three log > statements. If a new log statement comes in the first one disappears. > This log statement 'window' would move down if a new task is getting > executed. At the end of the build no normal log statement would be > visible. > > 3.) If the build is stalled you want to interrupt it and learn about > the reasons. Therefore we would implement a shutdown hook for the > JVM. This hook would print the complete recorded log to the console > (similar to the exception case). > > Additionally, the log can be written to a file. This will always be > the normal log, not the reduced form of the console. The log level of > the file log can be chosen independently. Of course if people don't > like the reduced form they can always switch to normal logging. The > Gradle logging behavior is either configurable via the command line > or by properties set in the gradle.properties file (either in the > project or in the gradle user home dir). > > I use the term 2-phase logging for this. If you have other ideas for > the terminology please let us know. > > What do you think about all this? > > - Hans > > -- > Hans Dockter > Gradle Project lead > http://www.gradle.org > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > > -- View this message in context: http://www.nabble.com/2-phase-logging-tp16945248p17913845.html Sent from the gradle-user mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
