On Jun 17, 2008, at 5:07 PM, Ittay Dror wrote:
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?
This is for convenience. It saves a step to the user. Even a failing
compile would make it necessary to look at the info log. So I think
it is nice to print it directly to the console in case something goes
wrong. The basic idea of 2-phase-logging (or any other name we want
to give to it) is: We have two log streams. One is the one which is
currently (Gradle 0.2) printed to the console (either info or debug
when using -d). The new log stream is neither info nor debug nor any
other standard log level. It gives high level information only about
which tasks are executed and in which order. Additionally it serves
as progress indicator. Once we have the two log streams it should be
up to the user what to do with them.
Use cases:
High Level to Console. In case of error info to the console and debug
to a file.
High Level to Console. In case of error debug to the console and no
file logging.
Info to the console, debug to a file (high level is not used)
Etc ...
This should be configurable via the command line or via the
gradle.properties file. Once we have the two logstreams our logback
logging engine makes it very easy to route the logstreams. In fact
logback makes it also pretty easy to generate the two log streams, as
it allows to create your own log levels (via Marker objects). It is a
really good tool, written by the founder of log4j.
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.
What you can do right now is: gradle -t
This prints all the available tasks and there dependencies to the
console. But you are right, this is not the specific DAG for a
certain task. I think it's a good idea to print this out as well when
in debug mode. http://jira.codehaus.org/browse/GRADLE-121
* 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.
This is not a particular problem of our two phase logging but two
phase logging might make it slightly worse.
For example:
INFO logging:
Executing: :compile
:: resolving dependencies :: org.gradle#buildSrc;SNAPSHOT
confs: [compile]
found #svnkit;1.1.6 in lib
found #svnkit-javahl;1.1.6 in lib
[groovyc] Compiling 13 source files to /Users/hans/IdeaProjects/
gradle/gradle-core/buildSrc/build/classes
If the last step takes long, the user gets no progress indication.
High Level logging:
Executing :compile
If this takes long we also offer no progress indication but the user
does not know whether this is because the compile takes such a long
time or if the remote repository is down when fetching the dependencies.
It depends on the kind of build if this really is a typical problem.
It will be configurable, so you can switch high level logging of.
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.
That would be really cool. May be not for the first implementation
but for the future.
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,
We would need a UI for this (which is fine). But it would be cool to
have also a boiled down version for the command line display.
- Hans
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
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
