ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Using files in classpath in task file=""
Date Fri, 04 Apr 2003 16:20:26 GMT

Stefan Bodewig wrote, On 04/04/2003 17.55:
> On Fri, 04 Apr 2003, Nicola Ken Barozzi <nicolaken@apache.org> wrote:
...
>>Because a URI can be navigated, and it's possible to make a File
>>from a URI.
> 
> Not always.

Agreed, not always with the same features. Listing files in a http URL 
"dir" is not usually possible for instance.

>>  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?

Yes, this is the question.

> <mkdir dir="http://www.apache.org/"/>
> 
> <delete>
>   <fileset dir="jar:http://my.server.com/applets/loader.jar">
>     <include name="**/*.gif"/>
>   </fileset>
> </delete>
> 
> means what?

Delete all gif files that are in the jar at 
http://my.server.com/applets/loader.jar.

Commons VFS deals with many providers to make this possible, but it's 
not always possible, as with http that is generally not writeable.

I would have the same problem if a local file was not writeable, it's 
consistent.

> If I sound harsh, please forgive me.  

Not at all, don't worry :-)

> 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.

Yes, I knew that in many cases this was going to happen. But the above 
would through an error, as it happens with other non-writeable files. 
IIUC the main problem WRT this is that URLs are many times not writeable.

> * 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.  

No... that's not how it's supposed to be. What other method do they need?

I can still navigate it, open it, read, sometimes write, all with the 
java.io.File signature.

> I.e. the change in
> IntrospectionHelper will only work for tasks that can handle it.

Are you sure?

> 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.

That again I would agree with. I believe that this solution can work 
*only* if we do not need to change the tasks *at all*. If we need to 
change the tasks, better using a new attribute.

>>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.

Yes, I know, but getting real:

  1) is that a real use case
  2) what makes it not possible or sensible to signal it's not featured?

>>Am I really missing the obvious? Could as well be.
> 
> Same here.

I think we are nailing it now :-)

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message