Hans Dockter wrote:
On Oct 31, 2008, at 9:09 PM, Adam Murdoch wrote:
2. It would be good if the source of the logging were considered when
routing info/stdout messages.
For example, a call to logger.info() or println() in my build.gradle
is almost always interesting to me when I run Gradle, and should be
printed on the console when I run with default options (ie should be
treated as a lifecycle message).
Right.
However, a similar call in a java library used by an ant task used by
a plugin is not interesting to me at all, and should not be shown
when I run with default options (ie should be treated as an info
message). There's a spectrum of interestingness going on here, and
I'm not sure how we decide whether an info/stdout message is
interesting enough to treat as a lifecycle message.
The same thing probably applies to warning and error messages. Some
warnings are just noise to me when I run Gradle, and some are
interesting.
This is pretty task specific I guess. For example one could argue that
the groovyc output should be send to DEBUG (I have chosen INFO for
now). Or external code writes errors or warning not to System.err but
System.out. Or vice versa (see the Ant code:
http://www.krugle.org/kse/codespaces/BLCNL5 Line: 153). Ant is usually
no problem for us, as we inject our own AntLoggingAdapter. But
sometimes this injection is hard or impossible to achieve (See for
example:
http://svn.codehaus.org/gradle/gradle-core/trunk/src/main/groovy/org/gradle/api/internal/dependencies/maven/deploy/DeployTaskWithVisibleContainerProperty.java)
Another issue is, that people will be often not aware of this
redirection. So they write a custom task and put some debug println
into it and, depending on our defaults, could have a very hard time to
figure out why they don't see it.
There is also the use case that you only want redirections for a
certain part of your code. For example the MavenUploader delegates to
the maven-ant-tasks (we can redirect the ant logging). But those tasks
use some Maven stuff which uses the logging of the Plexus container
(via a very modern inheritance based approach ;)). So we have to catch
standard out for the delegation call (See:
http://svn.codehaus.org/gradle/gradle-core/trunk/src/main/groovy/org/gradle/api/internal/dependencies/maven/deploy/BaseMavenUploader.java
method: execute).
All in all I would say the default for task execution should be to
send System.out to HIGHLEVEL and System.err to ERROR. The Java Plugin
then knows about the behavior of specific tasks and can define less
verbose rules for certain tasks. And the user can always have the last
word.
Ok. That way we keep it simple.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
