ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject RE: [WIP]Selectors
Date Tue, 05 Mar 2002 16:51:11 GMT
At 08:36 PM 3/5/2002 +1000, Adam Murdoch wrote:
>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


>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:   <>
For additional commands, e-mail: <>

View raw message