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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
