On Sep 23, 2008, at 10:55 AM, Adam Murdoch wrote:
Hans Dockter wrote:
On Sep 22, 2008, at 10:20 PM, Adam Murdoch wrote:
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?
I think this is good. Are there warning and error levels too?
Yes, definitely. The same as always, with the diiference that now
also Ivy and Ant logging is translated to the log level's of the
Gradle logger.
Are they always shown?
They are shown for all log levels including the high level log.
What would we do for the -q option?
As the high level log is already not very verbose I would say quiet
really means quiet (except exceptions that bubble up). For example
sometimes Ivy log an error although things are fine and the build
succeeds. In quite mode we would not show this.
If a user has very special requirements regarding the logging we
should provide a hook for a custom logback.xml.
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.
Possibly the -q option could work the same way too.
I could. But as the high level log is quiet on most of the stuff
(including all Ivy and Ant output) this might be of limited use.
One feedback I got from a discussion last night was not to have too
many different command line switches for logging. The alternative
proposal was to have one switch and pass a number to it which defines
the verbosity of the logging. Of course we could accept a second
argument denoting the area. I'm not sure what to think about this.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
