On Tue, 11 Feb 2003, Bruce Atherton <[EMAIL PROTECTED]> 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
