I apologize in advance if this is a duplicate send or the topic has otherwise been discussed in the last week. I recently switched email accounts and hadn't remembered to re-subscribe under the new address.
http://jakarta.apache.org/ant/ant2/actionlist.html#selector states: The selector API is one such mechanism to do this. The selector API will allow you to build file sets based on criteria other than name. Some possible criteria would be * Is the file readable? * Is the file writeable? * What date was the file modified on? * What size is the file? * Does the contents contain the string "magic"? If we end up supporting a VFS then we could expand the number of selectors considerably. A mock representation that has been proposed before is the following. Of course this is subject to change as soon as someone wants to tackle this action ;) <include> <selector type="name" value="**/*.java"/> <selector type="permission" value="r"/> <!-- could optionally be directory/or some other system specific features --> <selector type="type" value="file"/> <selector type="modify-time" operation="greater-than" value="29th Feb 2003"/> </include> --------- I've spent a bit of time thinking about this, and about the best I can come up with is that we need a more pluggable architecture than the representation above. With the javabeans approach, wouldn't it be possible to just to define an abstract superclass that <include> and <exclude> could accept with an "addFileSelector" type of argument? Then we could have things like: <fileset id="foo"> <include> <dir name="/projects/myproj/src"/> <file dir="/projects/myproj/src" name="/> <file src="/projects/myproj/include.files"/> <remote url="http://jakarta.apache.org/"/> </include> <exclude> <modtime after="29th Feb 2003"/> <modtime before="yesterday"/> <permission value="r"/> </exclude> </fileset> <fileset refid="foo"/> Each implementor of FileSelector could determine whether an "includesfile" was appropriate; in this case, <file src=""/> would be similar to our current <fileset includesfile=""/> (or for that matter, excludesfile) Each implementor of FileSelector would be able to define specific attributes that needed to be set -- no generic "operation", "value" attributes that make sense for one selector type but not another. This would also greatly simplify extending and providing your own custom file selector - just subclass FileSelector, add the task definition to your build file, and away you go -- the ant execution engine should take care of the rest. Each implementor of FileSelector would be responsible for returning an array or list of File objects, or even InputStream objects the latter might help in the quest for a VFS. Tim _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
