Logging

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Logging

hans_d
Administrator
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?

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Logging

Adam Murdoch-2


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.

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.

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.


Adam

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Logging

hans_d
Administrator

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


Reply | Threaded
Open this post in threaded view
|

Re: Logging

hans_d
Administrator

On Sep 22, 2008, at 10:46 PM, Hans Dockter wrote:

>
> 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.

I forgot to say: I hadn't thought about putting it in the build dir  
yet. But I think that would be the best location.

- Hans





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Logging

Adam Murdoch-2


Hans Dockter wrote:

>
> On Sep 22, 2008, at 10:46 PM, Hans Dockter wrote:
>
>>
>> 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.
>
> I forgot to say: I hadn't thought about putting it in the build dir
> yet. But I think that would be the best location.
>

Thinking about it, one problem with putting the log file in the build
dir is that we don't know where the build dir is until after the
settings have been built, which is quite a way into the initialisation.
We'd either have to buffer or discard log messages until after the
settings have been built.


Adam


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Logging

Adam Murdoch-2
In reply to this post by hans_d


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? Are they
always shown? What would we do for the -q option?

>>
>> 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.


Adam

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Logging

hans_d
Administrator

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


Reply | Threaded
Open this post in threaded view
|

Re: Logging

hans_d
Administrator
In reply to this post by Adam Murdoch-2

On Sep 23, 2008, at 10:51 AM, Adam Murdoch wrote:

>
>
> Hans Dockter wrote:
>>
>> On Sep 22, 2008, at 10:46 PM, Hans Dockter wrote:
>>
>>>
>>> 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.
>>
>> I forgot to say: I hadn't thought about putting it in the build  
>> dir yet. But I think that would be the best location.
>>
>
> Thinking about it, one problem with putting the log file in the  
> build dir is that we don't know where the build dir is until after  
> the settings have been built, which is quite a way into the  
> initialisation. We'd either have to buffer or discard log messages  
> until after the settings have been built.

That's right. It is even set in the project not in the settings.  
Buffering is possible but would introduce a couple of edge cases and  
is kind of unwieldy. We could put the log file in the top level dir  
by default but make it configurable. On the other hand we could put  
in in .gradle and give a hint that this file exists in case of an  
error. I think I prefer the latter.

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email