ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Rees <>
Subject Re: [RFC] permissions filters on file/patternset
Date Fri, 02 Mar 2001 19:40:18 GMT
I wanted to get it working a little better, but now that everyone is
talking about this...

I have a basic working prototype and am currently 80% complete on more
complete implementation of an extension to FileSet that I am calling a
FilteringFileSet that addresses the thoughts in this thread. I hope to
have the better version working by the end of this weekend.

I welcome thoughts and will also incorporate what people have said in
this thread as well. My hope is once I actually have a cleaner version
working (with tests) I can give more detailed functional and design
descriptions which can lead to more detailed thoughts ;). My current
description is below.

Also note that I am currently using the term "Culler" in my code as
the term Filter is already used in Ant. I am also playing with
"Selector". However, I think the description makes more sense when I
use Filter so that is what I use below pending a better name.



Generally a FilteringFileSet supports the abstract type FileFilter.
Concrete sub-types filter the files that are selected based on their
own rules. An obvious example would be file attributes (including
permissions and modification timestamp). Less obvious examples would
be based on file content or if the file is different relative to some
other location. Core to the idea is that adding a new FileFilter type
is as easy as adding a new Task type.

They would be used as follows:

<copy toDir="\tmp\toDir">
  <filteringfileset dir="\tmp\fromDir">
    <include name="*.txt" />
        modificationDateAfter="2/2/01 />
    <contentfilefilter includes="IMPORTANT" />

One problem is supporting a new sub-type for FileSet across all tasks.
I hope to extend Ant to support sub-types. If this causes problems
then a FilteringFileSet can always be defined outside a target and
then used by reference (refid) which I have verified works.


The design is straight forward. I have added FilteringFileSet,
FileFilter and a FilteringDirectoryScanner. The later is necessary
because the current DirectoryScanner actually does all the work and
FileSet is currently just a data structure. In my extended design
FileFilters do the real decision making for everything but patterns
(because I don't want to change all of that code) and
FilteringDirectoryScanner just asks them.

I am not modifying FileSet directly so existing builds are not changed
at all. Obviously if people like the idea, moving the code into
FileSet would be straightforward as well. Note, to be clear,
FilteringFileSet still supports PatternSets in the "old way". 

Possible Extensions:

FilterSet - This would allow reuse of filters across FileSets.

FilterSetFilter - Allows reuse of a FilterSet inside another

NameFileFilter - For completeness of design I may also introduce a
NameFileFilter that filters based on name (but it would be redundant
relative to PatternSets).

TypeDef - Like TaskDef for Types (like FileFilter sub-types)

Longer Term:

Longer term (2.0?) I think that PatternSets should be moved to be just
a sub-type of FileFilter.

I also agree with what Tim implies that we need to separate the source
from the filter. Currently in the code they are very much in the same
place (DirectoryScanner) which is why people have to create new
FileSets and Scanners for things like Zip. And in the XML they are
mixed as well. Something like this makes sense to me (we might
simplify for ease of use).

<FilterSet id="newImportantFiles">
  <PatternFilter filename="*.txt" />
        modificationDateAfter="2/2/01 />
    <ContentFilter includes="IMPORTANT" />

<FileSet id="tmpImportantFiles">
  <DirectorySource dir="\tmp" />
  <FilterSet refid="newImportantFiles" />

<FileSet id="webImportantFiles">
  <HttpSource url="" />
  <FilterSet refid="newImportantFiles" />

<FileSet id="tarImportantFiles">
  <TarSource tarfile="/stuff/files.tar" />
  <FilterSet refid="newImportantFiles" />

View raw message