ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: Resource.getURL() WAS Re: svn commit: r447990 - in /ant/core/trunk/src: etc/testcases/taskdefs/style/build.xml main/org/apache/tools/ant/taskdefs/ main/org/apache/tools/ant/taskdefs/optional/junit/
Date Thu, 21 Sep 2006 08:57:42 GMT
Xavier Hanin wrote:
> On 9/20/06, Matt Benson <> wrote:
>> I have been thinking it might make sense to add
>> getURL() to Resource.  Did a discussion on that
>> already take place?  I don't remember if it was
>> generally thought to be a good idea...
>> And, for example, what would we do for resources of
>> nonstandard "protocols"?  Would a StringResource with
>> value "foo" return "string:foo" as its URL?  Should we
>> install custom protocol handlers for built-in
>> resources and encourage the same be done for
>> third-party resource implementations?
>> Actually this sounds like a good idea to me.  Because
>> it seems to touch on the discussion we had before
>> about a string "encoding" to allow a Resource to be
>> specified as an attribute.  We talked about whether a
>> "type:stringconstructorarg" scheme would work... but
>> if IH knew that setFoo(Resource r) meant to treat the
>> attribute string as a URL and we had custom protocol
>> handlers installed for the built-in Resource types,
>> that would be just as good, if not better (I'm not
>> forgetting we would have to special-case protocol-less
>> strings to be interpreted as files for BC).
> I have no opinion about adding getURL () to Resource, but I think that
> adding an easy way to encode/decode a resource to a string is really a 
> must!
> And using a "type:" scheme is not really convenient IMHO. So using custom
> URL scheme sounds like a very good idea!

If a Resource adds getURL()

1. do it now, before ant1.7 ships
2. add some tests for resources that return null

Speaking of which, we have an NPE in a copy if the resource doesnt have 
a name:

    <copy todir="${build.dir}">
      <res:random size="8192"/>

leads to

--- Nested Exception ---
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.lang.reflect.Method.invoke(

I will file a bugrep. This is one of the things the antbook tests on 
gump should catch (random is an example resource to create a stream of 

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

View raw message