DirectoryScanner and MatchingTasks

[Mariusz Nowostawski <ma...@marni.otago.ac.nz>]

I am generating set of files in several directories, and I have to set
appropriate UNIX permissions on those files. I could use chmod task to do
that, but because there is a lot of files, and all of them can be easily
matched by modified chmod to be MatchingTask, I thought I will modify
chmod to be a MatchingTask, and then istead of sequence  of chmod tasks
in the build.xml I would need only one. (power of simplicity).

The current structure of chmod task is:

  <chmod src="filename" perm="permissions" />

which is nice, and it would be desirable to modify the task in such a way,
that it works fine as written above, and it also works with:

 <chmod src="directory" perm="permissions" include="**/*.sh" />

However, if we pass file instead of directory to the DirectoryScanner,
things do not go quite nice, as DirectoryScanner throws an exception,
complaining that passed thing is not a directory.

I can see several options here, one which would be to modify
DirectoryScanner to accept files as well as directories. In the file case,
getIncludedFiles() would simply return this single file. This would make
transition for some tasks to be MatchingTasks easy (like chmod). 

Of course, I can check inside the task what was passed to it, a directory
or a file and take appropriate action.  But the latter means doing it in
more of MatchingTasks, which is "code duplication" ;o)  

I can implement the former or the latter, but I would rather modify
DirectoryScanner.... 
If I ask: give me all files in this: "/usr/local/bin/", getIncludedFiles
should of course return set of files, but for: give me all files in
"/usr/local/bin/ant.sh" it should simply return me single "ant.sh" file.

Options once again:
1. Modify DirectoryScanner to accept files as well (the check whether it
   is a file or directory is done inside DirectoryScanner) - the code for
   some Matching Tasks is simpler and more uniform.

2. Modify just chmod (and others) tasks to be Matching Tasks (when it is
   appropriate). This would require a check whether "src" is directory or
   a file and react accordingly to that in each single Matching Task.

3. others

If we could decide what is nicer I can do it and submit a patch.
What do you think? 

What about moving other tasks to MatchingTasks:
chmod (work in progresss ;o), exec (patched already, but without
sequential mode), expand, get, gzip, java (not sure this one makes sense
though, maybe when executed sequentially), others?  rename could be done
this way, but need more work, for example to rename all java files in one
directory to .java.orig we need to have a way to specify current matching
filename and extenstion to make the patterns right.


What about having a list archive ;o)  At least we could get from there
patches posted to the list before, or some Patch archive on the web...
I remember somebody posted a patch with ftp task, could you please pass
it to me as I haven't thought at the time of reading your post that I will
need ftp task before the new Ant hopefully with it will be released?  ;o)
BTW I think this task could be called "put", to make a pair with
"get". Alternatively I think we need "put" anyway in new Ant (and of
course "put"should be matching task as well whoever is going to 
write it  ;o)

cheers
Mariusz