ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Rees <>
Subject Re: [DISC] Datatypes
Date Tue, 27 Mar 2001 21:06:54 GMT
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.
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.
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.
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.


On Tue, 27 Mar 2001 10:58:54 +1000, Tim Vernum wrote:

>From: Conor MacNeill []
>> From: "Stefan Bodewig" <>
>> > * 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.
>    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
>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 
>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.

View raw message