ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: adding getURL() to Resource [WAS: [Bug 39407] - Change <xslt> task to accept the XSLT stylesheet as a resource]
Date Thu, 08 Jun 2006 09:13:56 GMT
Matt Benson wrote:
> --- Antoine Levy-Lambert <> wrote:
>> Hi,
>> XSLT processing, and maybe other tasks would need a
>> method getURL() to be added to Resource.
>> Any thoughts on that ?
>> If we do it, do we do :
>> String() getURL() 
>> or
>> getURL()
> Hmm.  I'm not smart enough for this.  I guess we
> probably should as file resources have urls.  What
> does that say for <url>?  Is that a conflict, or is it
> just the most generic of the "real" resource types? 
> If we make it part of the resource then I would think
> we should use the actual URL type; in fact URLResource
> already has this property, so it already implements
> this.  This way custom resource implementations could
> create the URL they return with a custom
> URLStreamHandler and the resulting URLs would be able,
> with sufficient JVM permissions set, to behave
> appropriately for whatever resource is declared.  How
> does this sound to anyone who cares?

ahh, now we are getting complex

Remember that (somehow) even JAR entries can become URLs (see 


Which even gives us insight into jar/zip files.

What we cannot do is trivally add a new tar: url, or the like, primarily 
because the URLConnection logic is always implemented in the base 
classloader, possibly restricted to extension libraries, I forget. All I 
do know is that in some bit of smartfrog I had to add URLs and had to make sure that everything 
that wanted to load it had to use their own factory stuff.

Things that dont use the custom factory (like, say, Xalan), couldnt 
handle custom URLs if they were passed down as strings, embedded into 
XSL sheets, etc.


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

View raw message