ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Rees <>
Subject Re: What I did to DirectoryScanner
Date Tue, 27 Mar 2001 20:17:29 GMT
Defining them as rules for including files certainly does make sense.
What I am saying doesn't make sense is that DirectoryScanner class
actually maintains this distinction in its results. After scanning it
has three sets of values for file and another three for dir. They are
notIncluded, excluded and included. I think that excluded as part of
the result set doesn't make sense and the existence of excluded in
fact results in "included" being a  misnomer because it is actually
files that were included but excluded.


On Sat, 24 Mar 2001 12:15:38 -0600, Chris Greenlee wrote:

>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