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, 20 Mar 2001 22:07:30 GMT
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?


View raw message