Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org Received: (qmail 1711 invoked by uid 500); 20 Mar 2001 20:06:10 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk Reply-To: ant-dev@jakarta.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 1667 invoked from network); 20 Mar 2001 20:06:04 -0000 From: David Rees To: ant-dev@jakarta.apache.org Subject: Re: What I did to DirectoryScanner Date: Tue, 20 Mar 2001 11:57:35 -0800 Reply-To: d.rees.l@usa.net Message-ID: References: <5fm4btk32vd8g3rjee6vsdrf8ftu7e2cti@4ax.com> In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 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? d