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
