ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [PATCH] Copy task recognizes URLs as file attributes
Date Wed, 28 Nov 2001 00:11:24 GMT
On Wed, 28 Nov 2001 09:40, Steve Loughran wrote:
> >My point is why should the protocol matter?  Why *shouldn't* the attribute
> "file" be overloaded?

because people don't think of files and urls as being synonymous? ;)

> 1. it aint a file, it is a URL. I know that you can argue that it is a
> remote file, but that assumes that the url endpoint is 'legacy' static
> content, not some dynamically created or retrieved thing.

or that URL actually has an endopoint. How would you copy a 
"mailto:peter@apache.og" url ? ;)

While I do like the concept of urls as general resource directory I think it 
needs to be done at a virtual filesystem level. Then we could query the 
"file" to see whether it supports operation X (where X may be read, write, 
getType, getName, canRead etc)/

> 2. The more information we provide in the XML syntax, the less
> interpretation which needs to be included in the runtime, which gives more
> flexibility in the future. Example: with a URL= syntax you could have an
> XSLT task which treated file= assignments differently from url=
> assignments.
> My friend Gabe, serious XML hacker, once took me aside and listed all the
> places where ant was naughty and used hid structure inside an XML literal
> instead of on the outside, which roughly comes down to wherever we used a
> list and wherever an attribute was overloaded:
>  <target depends="task1,task2" >
>  <exec os="windows 2000, unix" > (actually this is worse, as we just
> substring match, so "windows" would still get a hit>
>  includes="...", excludes="..."

yep ;(

> Now, some things have happenened, and they are frozen in the ant 1.x
> syntax. But we dont need to make things continually worse, do we?

hope not. Especially not with the depends attribute ;)

> 3. Remember that email about how we should have consistent property names,
> srcFile and srcDir, destFile and destDir. Using srcURL and destURL would be
> consistent. Yes, I know that <copy> isnt consistent with this scheme, but
> that is a historical feature. We could make it consistent...

we should really go through and make a list of all the ones already in 
existence and then try to draw something from that. I seem to recall that 
copy actually moved away from that syntax for some reason.



"If you don't know where you want to go, we'll make 
sure you get taken." 
Microsoft ad slogan, translated into Japanese.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message