Hi Xavier,
great to see you on the list :)
On May 5, 2008, at 1:57 PM, Xavier Hanin wrote:
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.
I'm not sure if I understand. Therefore a stupid question. The
problem you mention here would occur if Gradle would go for the
approach of having a 'command-line window' of the last three or
whatever log statements? It would be no problem if we would use dots,
right?
- Hans
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/
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
