Hi Stefan,
On May 6, 2008, at 9:21 AM, Stefan Groschupf wrote:
Just my 2 cents...
Mercurial style - as less as better.
I think just printing the executed tasks is more or less the least
noisy level after quiet (which you can choose right now already via -q).
Also beeing able to configure it easily in user properties would be
nice. I might like it more noisy than other users.
Definitely. We are going to offer configuration via project
properties and/or user properties.
I saw tools that have more log level than just info, warn, error,
debug. For example those tools had loglevel 0 to 10. Zero mean
actually zero output - and 10 would be very verbose. Maybe overhead
maybe difficult to decide which msg is which level.
Right
The best of course would be make things easy pluggable. Than over
time if people feel very emotional they can implement there own -
one star instead of point for each executed task - logging tool.
Optional fine grained configuration would be cool.
I mean right now you can do only the best guess but over time with
more users requirements will adjust anyhow...
Right.
Thanks for your feedback
- Hans
Again just my 2 cents.
Thanks for all your good work Hans!
Stefan
On Apr 28, 2008, at 4:03 PM, kkrugler wrote:
Hi Hans,
In general I think this would be a nice improvement over Ant/Maven
build
output.
See below for some short inline comments.
-- Ken
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.
KK: Yes, definitely
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.
KK: I would do something simple - e.g. print a dot for each
logging call
:-)
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).
KK: Good idea, yes
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-tp16945248p16945976.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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
101tec Inc.
Menlo Park, California, USA
http://www.101tec.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
