On Sep 22, 2008, at 10:20 PM, Adam Murdoch wrote:
Hans Dockter wrote:
Hi,
I have submitted some work to make the default logging less noisy
in the future. What it does is to catch all Ivy and Ant output and
delegate it to slf4j. There is now also a slf4j marker called
HIGH_LEVEL. Any logging statement having this marker is supposed
to be shown by default on the console. There is one problem left
to solve. The Groovy compile is happening in its own classloader
(to enable using a different Groovy version for Gradle Groovy
projects than the one shipped with Gradle). We have to rearrange
things that this compile is also using the same loggers.
Beside this there is one usability question. On the console we
will have a minimized output. Should we write the current verbose
console output to a file by default?
Probably. Which file would it go to? $rootDir/.gradle/gradle.log,
$rootDir/gradle.log or $rootDir/build/gradle.log seem like good
options to me.
I'm not sure. The gradle.log in the top level dir would have the
advantage that people would learn simply from using Gradle that there
is such a file. On the other hand it pollutes the top level dir which
is something many people feel rather sensitive about.
We'd need a command-line option to override this, and it also seems
like something you'd want to override in your gradle init file.
We could use system properties for this as you can also set system
properties in your gradle.properties file. You want to specify for
file logging (none, info, debug) I guess.
My current idea is to have three log levels (HIGH_LEVEL, INFO, DEBUG)
and two appenders (console and file).
The default would be: HIGH_LEVEL/INFO
The criteria for HIGH_LEVEL is: Should only indicate progress and
which tasks are executed. By being not verbose it does not hide
warnings/unusual things (like our very verbose output does now).
INFO: Used by the user to figure out why the build has failed. Should
offer enough information to find the reason in the most cases.
DEBUG: Used by Gradle developers to learn about the internal Gradle
behavior. Used rarely by the users to figure out problems.
What do you think?
Something I'd like is the ability to control from the command-line
the logging levels for broad functional areas, such as the
projects, ant, ivy, groovy and gradle itself. We have this for ivy
already, it would be nice to generalise this a bit. For example,
gradle -d ivy -d ant would enable debug level for all ivy and ant
logging. Or gradle -d projects would enable debug level for my
project's logging.
This is funny. I was thinking in the opposite direction and removing
this special Ivy switch. My motivation has been to simplify things
for our users. But looking at your proposal we can have both worlds.
Just using -d will enable debug for everything, -d <area> only for a
subsystem. Right now -i is used for making Ivy output silent. This
will be no longer necessary with our high level logging. My idea is
to use the -i option the same way we plan to use the -d option, but
for the info level.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
