ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: API changes introduced while fixing bug 10755
Date Wed, 12 Feb 2003 08:35:36 GMT
On Tue, 11 Feb 2003, Bruce Atherton <bruce@callenish.com> wrote:

> This is in large part a conversation about the colour of a bikeshed,

8-)

> ResourceUtils would still work,

I can go with that, no problem.

> OTOH, perhaps the methods in SelectorUtils fit within the contract
> of SourceSelector and should be folded into it, perhaps with a
> broadening of the types of parameters that are accepted.

I'll look into it.

> Eventually we'd like a future where Scanners can be used
> interchangeably in all tasks, no?

Probably yes, it would jump out of the polymorphism ideas in a way.

>> > Is it necessary that Scanners call the logging API?
>>
>>Not really.  System.err would probably work.  The problem are debug
>>messages that you normally would want to suppress, we can as well
>>drop them.
> 
> Regarding System.err, that seems unnecessary to me if you are
> willing to throw BuildExceptions (unless I'm missing something).

BuildExceptions for sever errors, System.err for what we'd log with
MSG_ERR priority, System.out for MSG_INFO was the idea.

> then logging probably is a better solution than System.err even if
> it complicates the API. It gives more control to our logging
> infrastructure.

True.  I could as well pass in an org.apache.tools.ant.util.TaskLogger
instance.

> As for debug messages, the question is whether you need access to
> the Scanner internals for debugging, or if all you need is
> information about the external behaviour (which can be logged at a
> higher level in the program).

There currently are debug level messages that need access to the
internals, I'm not sure how much valuable information they'd provide
though.

Stefan

Mime
View raw message