On 3/08/10 1:34 AM, Russ Rollins wrote:
Not having much luck here, and have confirmed that when using
ProjectBuilder and obtaining an instance of a Project, the following
assertions fail:
assert proj.logger.isEnabled(LogLevel.LIFECYCLE)
assert proj.logger.isEnabled(LogLevel.INFO)
assert proj.logger.isEnabled(LogLevel.DEBUG)
assert proj.logger.isEnabled(LogLevel.ERROR)
assert proj.logger.isEnabled(LogLevel.WARN)
This is a very clear indication to me that when using ProjectBuilder
to test custom plugins and tasks, the underlying Project instance used
in testing is swallowing the logs.
After looking at the source (0.9-preview3) for ProjectBuilder it
appears that the StartParameter does not set a default log level--thus
if attempting to run the tests with "-i" the log level is limited to
the invocation of the top-level Gradle instance and not cascaded to
the Gradle instance executed when using ProjectBuilder and invoking
custom tasks or custom plugins.
In my attempt to enable logging, from the Project instance provided by
ProjectBuilder, I tried to manually set the log level on the
StartParameter from the Gradle object associated from the
instance--which was also unsuccessful. So at this point, it looks as
though creating plugins and tasks, while relying on their native use
of the logging API granted through inheritance, cannot be expected to
generate the log statements via the API in a testing environment.
The real question is whether this is a bug, or logging for
ProjectBuilder Project's can be enabled through some undocumented means?
There's a couple of problems causing you grief here:
- The ProjectBuilder does not configure any logging. It assumes it is
running in an environment where slf4j is configured appropriately.
- The tests are not automatically run with any slf4j binding or
configuration, so, unless you do something about it, sl4j just swallows
all logging messages.
These are possibly not very useful behaviours. A work around would be to
include an slf4j binding in your testRuntime classpath.
Could you add a JIRA issue for this problem?
Some possible solutions to the problem:
- The gradleApi() dependency automatically includes logback in the
testRuntime classpath.
- More generally useful might be to combine the above with some way to
specify a log level on the Test task, which would then configure
whichever logging toolkits happen to be included in the testRuntime.
This might also be useful on the JavaExec task, too.
I'm not 100% sure the ProjectBuilder should do any logging
configuration, but that could also be part of a solution.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
