ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Rees <d.ree...@usa.net>
Subject Re: [SUBMIT] Cullers (finer grained selection in FileSets)
Date Wed, 14 Mar 2001 19:54:51 GMT
Anyone have thoughts on this? I have seen four questions/requests in
the past week on ant-dev/user that this functionality would help with.

I am going to start the second cut tomorrow with the changes I listed
in the previous email. If people have suggestions I would like hear
them sooner rather than later so I can incorporate them this go
around.

dave

On Fri, 09 Mar 2001 16:28:03 -0800, David Rees wrote:

>Attached is my first cut at the culler functionality I mentioned last
>week. It doesn't include HTML updates yet because I think text
>will better facillitate  discussion. Below I describe using cullers
>and how to write additional cullers (which is very easy). I think its
>ready to go in its current state, but I have a second round on
>enhancements that I have planned to be ready in about a week
>(these are described below). I also wanted to get this cut out to
>receive comments for changes in the next round.
>
>Its about 5 days late due the incredible pain I endured and hoops I 
>had to jump through trying to get VisualAge to play nice with the
>source and not scramble it. Happily I now have hacks and scripts to
>deal with this for future work (now the hoops are lower to the ground
>and are no longer flaming ;).
>
>My thoughts for how this "should" be done in Ant2 will be in different
>post (later), but the generally idea is the same.
>
>dave
>
>
>** Usage
>
>The changes extend FileSet to support "FileCullers". A FileCuller is
>an abstract type for a class that determines if a file should
>selected. Concrete sub-types are based the baseDir and relative path
>and do whatever they like to decide about selecting the file. The
>current implementation includes a atrribute-based culler and a culler
>set that supports grouping and simple logic. However, core to the
>design is that new sub-types of FileCuller are easy to add. 
>
>An example says it best:
>
><copy toDir="\tmp\toDir">
>  <fileset dir="\tmp\fromDir">
>    <include name="*.txt" />
>    <AttributeFileCuller canWrite="no" />
>  </fileset>
></copy>
>
>Selects all files that end in ".txt" and are read only.
>
>
>* AttributeFileCuller
>
>AttributeFileCuller current supports the following attributes. Their
>function is pretty clear and they match the corresponding method on
>File. The default for all of them is ignore so a blank
>AttributeFileCuller
>will select all files. Also planned is lastModified and length which
>will
>have a greater than, less than syntax of some sort.
>  canRead	- true/yes, false/no, *ignore
>  canWrite	- true/yes, false/no, *ignore
>  exists	- true/yes, false/no, *ignore
>  fileDir	- file, dir, *ignore
>
>
>* FileCullerSet
>
>Collection of FileCullers that is also a FileCuller itself
>(they can be nested). Supports the following attributes (* is
>default):
>
>  logic - and*, or
>  Used to indicate what logic is used to combine my nested cullers.
>
>  not - true/yes, false/no*
>  If "true/yes" the FileSetCuller's value is reversed.
>
>Cullers are applied in the order they are listed. Short circuiting is
>used (e.g. the first false nested culler with
>"and" logic will result in the FileCullerSet returning false).
>
>For example:
>
><copy toDir="\tmp\toDir">
>  <fileset dir="\tmp\fromDir">
>    <filecullerset>
>       <attributefileculler fileDir="file" canWrite="yes" />
>       <attributefileculler fileDir="dir" />
>    </filecullerset>
>  </fileset>
></copy>
>
>Selects all directories and only writable files. 
>
>
>* Caveats
>
>Unlike patterns, cullers do not effect what directories are scanned,
>they only effect what directories are included. This is by design
>since the reverse makes them much less useful. Patterns still do
>effect what directories are scanned and are applied before a cullers
>are applied. One thought is to somehow support the option of
>indicating a separate set of scan cullers.
>
>Some subclasses of FileSet/DirectoryScanner may not support certain
>FileCullers because they assume files (e.g. ZipFileSet). In this case
>the user will receive a build exception that the file (which in this
>case isn't really a file) does not exist. The possible extension below
>of having the culler ask its scanner for the file will result in the
>same limitation, but a nicer message.
>
>
>* Extending
>
>Additional FileCullers can be added easily by creating a subtype that
>implements shouldCull() and then adding the add<ElementName> methods
>to FileSet and FileCullerSet.
>
>
>** Plans
>
>Add lastModified, length to AttributeFileCuller.
>
>Add xor to FileCullerSet.
>
>Create CompareFileCuller which will select files based on comparison
>with another directory. Will support culling files that exist, don't
>exist or that are different. Can be used with delete/copy for
>rsync/robocopy functionality. Possibly will use Mappers?
>
>Create ContainsFileCuller which will select files based on their
>contents using a RegExp.
>
>PatternFileCuller - for completeness and to support fine grained
>control than available using just patterns.
>
>Make FileCullerSet a DataType so it supports id/refid.
>
>Use CullerSet in FileSet and DirectoryScanner rather than a Vector.
>
>Cleanup FilesetCopyTest to support easy extension for new Cullers.
>
>
>** Possible Plans
>
>Possibly introduce PathCuller as super-type to recognize that not all
>sources are file based.
>
>Possibly pass DirectoryScanner to cullers so it can be used to access
>the file. Cullers would then request their file (if they use one) from
>the scanner. Allows a variety of different scanners to be used with
>cullers. A build exception would be raised for requests that the
>scanner does not support (Vaj). Also, lends itself to later supporting
>streams for stream-based cullers so that any variety of non-File
>sources can be used transparently (FTP, VAJ, Zip).
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ant-dev-help@jakarta.apache.org


Mime
View raw message