Overall I like this idea too. There's one thing which can become tricky is handling the processing of logs if you use the parallel ant task. removing the last log line when you have concurrent logging require good thought and good testing.
Xavier On Mon, Apr 28, 2008 at 8:34 PM, Hans Dockter <[EMAIL PROTECTED]> 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 > > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
