ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Greenlee <>
Subject Re: What I did to DirectoryScanner
Date Sat, 24 Mar 2001 18:15:38 GMT

I'm not sure if this applies to cullers, but having both an include and 
an exclude does make logical sense -- I might want to include every 
member of a group except certain members of a sub-group.  e.g., I might 
want to include all files of the form *, but exclude those that 
live in a directory named example.

I'm not sure if there's an analogy for cullers, though. :)


Chris Greenlee

David Rees wrote:

> On Tue, 20 Mar 2001 11:57:35 -0800, David Rees wrote:
>> On 19 Mar 2001 10:23:49 +0100, Stefan Bodewig wrote:
>>> David Rees <> wrote:
>>>> While we are on the subject, is there really a reason for the
>>>> excluded and non-included parts of DirectoryScanner?
>>> I've never seen anybody use it, but it has been there from the start -
>>> so we could potentially break some environments if we'd drop them.
>> The problem is I would like to make a nice simple culler interface
>> like shouldInclude. But to support these three layers of "inclusion" I
>> need to have shouldInclude and shouldExclude which really doesn't make
>> sense to me. As a small note, the naming inside DirectoryScanner is
>> not consistent. "filesIncluded" returns files included and not
>> excluded (as opposed to files included).
>> Actually, what I really think is happening is that there needs to be a
>> shouldScan for directories which is what the shouldInclude is really
>> being used for (to avoid descending on directories that can never
>> contain files to match). Then nonIncluded becomes non-scanned,
>> excluded is scanned-but-included and included means
>> scanned-and-included. Maybe do this and keep the old APIs for
>> backwards comparability?
> Well, I dived into the code some more and I think I (slightly?)
> misrepresented the situation. My core problem is with the distinction
> between notIncluded and excluded. This requires knowledge at the
> Scanner level of include/excluded which doesn't make sense outside of
> patternsets. As an example, the culler interface I want is just
> "shouldInclude" but to support the excluded set I need a
> "shouldExclude". That doesn't really make sense for things like a
> attribute culler. Also, "shouldInclude" is a misnomer because the
> scanner only adds a name to the include set if the name passes both
> shouldInclude and shouldExclude.
> My current gut, do-no-harm feel is to support both shouldInclude and
> shouldExclude in the culler API. But the average culler (e.g. every
> culler but path culler) always returns false for shouldExclude so that
> the average culler developer only thinks include or not include?
> d

View raw message