Drop it out of the interface, then at least the abstraction can be reused elsewhere. Some of the implementations will work outside Ant, and others won't.
Right.
BuildException is pretty general. There's not really any reuse problems there, except for maybe the name. If you really don't want to throw BuildExceptions, create a new exception type.
You've convinced me about BuildException. Creating a different exception would just make things harder to use, since in ant everyone would just catch the new exception and rethrow it as BuildException. No point making the API any more complicated to use than necessary. And it appears that BuildException is independent of the rest of ant, so you can get the banana without the 700 pound gorilla.
The interface doesn't have to be stateless. If you do want to go with a stateful interface, perhaps rather than adding a reset() method, change the contract for assignBaseDir(), so that it is responsible for resetting state.
I guess my real question is whether anyone would find it useful to find out which selectors approved or disapproved of a file. I see all kinds of methods in FileScanner for getting the set of excluded and the set of not included files and directories. Do people actually use those? Would they find an expansion of those abilities useful?
I would have thought the only information a task cared about was whether to use a file or not, which would mean that you could make it stateless. But if there are uses for the information about files that are not selected, and those uses would be helped with more detailed knowledge about why a file was not selected, then it makes sense to keep state.
If you don't need that flexibility (and we don't here), then using an add method gives future version of Ant a few more options, for example, to automatically set references, or to use a subtype in place of the add method's type.
Interesting. I didn't realize this about Ant2. I'll keep it in mind, thanks.
> The benefit to your view is that we don't > get patternsets within patternsets. The disadvantage is that patternsets > can be top level tasks, and there is a resistance to introducing new ones. >
Is there? Maybe to vendor or project specific tasks, but not something general like a selector container.
That was a thinko, sorry. Where I said "tasks", I meant tags that can exist outside of a target.
If there is no resistance to adding selectors as direct elements of <project>, then the disadvantage disappears.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
