On May 6, 2008, at 7:28 PM, Xavier Hanin wrote:
On Tue, May 6, 2008 at 10:49 AM, Hans Dockter <[EMAIL PROTECTED]>
wrote:
Hi Xavier,
On May 6, 2008, at 1:16 AM, Hans Dockter wrote:
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?
I was pretty tired when I did not understand.
For multi-threaded builds I see two problems. One is what we show
when an exception occurs. My idea would be to group the log output
by thread. The last group that is shown would be the group where
the exception occurred. We could this grouping either via thread-id
or ThreadLocal appenders. It is another question if the build
should always stop in case of an exception. If not we could do the
same grouping, but the log for the failing thread wouldn't be at
the end then.
Grouping by thread is nice. But this is only when a problem occurs.
If the info level is enabled, you log statements as they come.
Right, only if a problem occur. But otherwise the default way would
not to print info, but to print only that a task is starting to get
executed. INFO is more verbose. The user can choose whether Gradle
should use 2 phase logging (Details are only shown in case of an
error) or normal INFO(or DEBUG) logging.
But do you allow to log messages without an EOL? In Ant, System.out
is captured, and actually sent to the console only when an EOL is
reached. This makes reporting progress very difficult (you've
probably seen the dots with strange breaking lines in Ivy).
Interesting to learn about this ant behavior. I haven't known this.
Now I understand the dot handling of Ivy.
Gradle uses logback under the hood for its logging. We can create an
appropriate appender.
The other problem is how to indicate progress. One way I can see
right now would be to offer a little swing app for this. But I'm
not too fond of this idea.
Many people that I know really don't like this, including me. I
often build stuff using an headless connection, in which case the
swing app can't be displayed. So I think gradle need to have a good
progress indicator mechanism on the console, pluggable when used
from a rich client environment like an IDE. For the console
progress, I really like what they do in Maven when downloading
artifacts for instance, but this doesn't work in multi threaded
environment, at least not easily. IMO it would be nice to have a
progress indicator API independent from the implementation (the
progress indicator API in eclipse can be a good source of
inspiration IMO).
Very interesting idea.
Then you can start with a simple implementation, outputting dots
for instance. Later when gradle will be used all over the world by
billions of people you'll have zillions of contributions to provide
a better implementation, with screen flashing and ascii art games
to entertain build engineers during boring days :-)
And every Gradle user is an Ivy user. We have to spend the rest of
our life responding to the mailing lists ;)
- Hans
Gradle plans to support multi-threaded builds in the future.
Nice. With multi core systems everywhere, I can't imagine a single
threaded build system as a solution for the future.
Xavier
- Hans
- 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
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
--
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
