ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
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 <> wrote:

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


> 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

> 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


View raw message