I completely agree that DirectoryScanner should be redone. Specifically I like the followings (listed to better explain what I am talking about from a developers API perspective, not to indicate a specific design ;):
* Scanner Searches a hierarchial Source applying Cullers to select which paths make it through. API: Scanner(CullerSet, Source); String nextPath(); * Source A source that can some hierarchial structure and for some sources can provide a stream or file for a given relative pathname. API: getFile(String aPath); // throws error if no File support getStream(String a Path); // throws error if no Stream support * Culler Takes a source and a path and says yeah/neah. API: boolean shouldInclude(String aPath, Source aSource); Then any sub-type of the above will work. Also, the Ant core needs to support subtypes. Right now it can't because of the way IntrospectionHelper works. It looks for a element names on the container element and looks for elements with those names. Instead, IMHO, it should map that element name to a type and then look for that type or sub-types. To better explain if I support addFileSet(FileSet aSet) then I should allow a nested ZipFileSet as well without having to add another add* method. dave On Tue, 27 Mar 2001 10:58:54 +1000, Tim Vernum wrote: >From: Conor MacNeill [mailto:[EMAIL PROTECTED] > >> From: "Stefan Bodewig" <[EMAIL PROTECTED]> > >> > * Make all datatypes interfaces to allow them to be >> customized in many >> > ways. >> >> -0, Not sure what the motivation for this. > >I requested this, so let me explain. > >Currently, a FileSet is a class. >To retreive the set of file that a FileSet "holds" you ask it for >a DirectoryScanner, which is also a class. >I consider DirectoryScanner to be primarily an implementation details >for filesets (ie, Its purpose is to provide a programmatic interface >to the contents of the fileset.) > >DirectoryScanner exposes a lot of implementation details. >eg: > public void setIncludes(String[] includes) > public void setExcludes(String[] excludes) > >I would consider that a FileSet is just a set of files. >That fact that a FileSet is currently defined as a set of >include/exclude patterns should be irrelevant to the task >writers. > >As far as any task is concerned, supporting a nested FileSet >means you support a list of files. >Any task that supports filesets should support a set of files >that is not defined in terms of include/exclude patterns. > >There have been times when I've wanted to generate a set of >files in some other way than through include/exclude patterns. > >I would like to have been able to do something like: > >public class MyStupidFileset implements FileSet >{ > public File getNextFile() > { > ... > } > public boolean isDone() > { > ... > } >} > >[ alternatively, this could be MyStupidDirectoryScanner ..., > I don't care either way ] > >But as it stands now, all tasks expect a FileSet to return a >DirectoryScanner, and a DirectoryScanner is interfaced thus: > > public String[] getIncludedFiles() { > public String[] getNotIncludedFiles() { > public String[] getExcludedFiles() { > public String[] getIncludedDirectories() { > public String[] getNotIncludedDirectories() { > public String[] getExcludedDirectories() { > >If I want to generate files in some other means, then the above >interface is not at all suited. > >Ultimately, my belief is that core datatypes (and associated >utility classes like DirectoryScanner) should have an interface >that describes their purpuse/function rather than their >implementation. >I also think that once that interface is defined, then it >should be provided as a java interface, to make it explicit >what the contract with task writers is. > >I think I've waffled on enough there. >I hope that makes some sense.
