On Fri, 04 Apr 2003, Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote: > Sure. Look at the JDK 1.4 version,
Ahh, far to modern for Ant. > Because a URI can be navigated, and it's possible to make a File > from a URI. Not always. > org.apache.tools.vfs.File extends java.io.File But this version cannot be the argument for the (existing) setters. For this to work, IntrospectionHelper will need to take special care (i.e. if setXYZ(java.io.File) is found, actually pass it an instance of org.apache.tools.vfs.File). This is possible, but ... * Is this generally desirable? <mkdir dir="http://www.apache.org/"/> <delete> <fileset dir="jar:http://my.server.com/applets/loader.jar";> <include name="**/*.gif"/> </fileset> </delete> means what? If I sound harsh, please forgive me. I'm trying to show that in some situations it may be better to stick with files and we need a way to distinguish them. * is not as transparent as you say. Tasks could only use the URI if they first check that the object is is our version of File and cast to it. I.e. the change in IntrospectionHelper will only work for tasks that can handle it. Both points mean that it becomes hard to explain when URIs can get used and when not. Just as people have by now become so used to the relazive path resolution magic that happens inside Ant that they now report it as a bug if a ceratin attribute is not resolved relative to basedir, we will get bug reports that certain tasks do not deal with URLs of protocol foo properly. I find it hard to imagine that we'll be able to convert all tasks that could reasonably be expected to deal with URIs in one go. > if I gave you just an url in the constructor, you could write > almost, if not all, those methods. That really depends on the protocol you use. delete() for resources loaded from a jar located on a remote server, loaded via some P2P protocol? I may be making up things, I know. > Am I really missing the obvious? Could as well be. Same here. Stefan
