Well we also have the <record/> loggers. Which although not controlled
by the commad line, I think they should have the same rights to events
as "the logger" (otherwise they are useless for debugging sections of
a build).
The logger is special. It has the right to write to the original System.out stream. No other listener has that right. <record/> instances are not BuildLoggers, they are BuildListeners. The specialness of the command line logger does not affect the "rights" of other listeners to receive events.
It you can decide not to issue messages, you can decide to change the behavior of your task in a more radical fashion. But nevermind this point.
Still if we want to have such functionality what we would need is an API in project to check for current "logging level of interest" that internally will consult ALL BuildLogger2 instances and give the aggregated answer. Such a system will work in the presence of <record/> loggers.
That would be BuildListener2. There's a difference. I still think there is value in being able to control the logger. Being able to control the threshold in the logger (without affecting events sent to other listeners) would be useful for script debugging. I've always found <record> to be somewhat cumbersome.
Conor
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
