ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: testing for verbose mode
Date Fri, 09 Jul 2004 10:36:42 GMT
> From: Conor MacNeill [mailto:conor@cortexebusiness.com.au] 
> 
> 
> Jose Alberto Fernandez wrote:
> > 
> > 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.
> 

This is just a technicallity of of the current implementation.
The whole point of <record/> is that you want to save the messages
coming from a particular section of your build into a file.
Mostly for debug purposes, that is why it has a loglevel attribute
in there.

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

Try to find a bug with -debug in a recursive 1000 lines buildprocess.
The output is so big with 99% of it just noise for the purpose of the 
bug you are trying to trace. <record/> is the only tool we have today
so you can just ask for detail debug output of the particular section
where
your script (for example) is been called.

I agree with you record is quite conversome to use at the moment. I just
filed a bug to see is we get some more functionality to it.

Jose Alberto


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message