On 9/20/06, Matt Benson <[EMAIL PROTECTED]> 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!

-Xavier

This sounds pretty involved.  We could go ahead and
add getURL() to Resource, having it throw
UnsupportedOperationException by default, or we could
wait.  In either case, post 1.7.0, we could run with
the custom protocol handling idea.

Community?

-Matt

>
> Regards,
>
> Antoine
> -------- Original-Nachricht --------
> Datum: Tue, 19 Sep 2006 21:58:19 -0000
> Von: [EMAIL PROTECTED]
> An: [EMAIL PROTECTED]
> Betreff: svn commit: r447990 - in
> /ant/core/trunk/src:
> etc/testcases/taskdefs/style/build.xml
> main/org/apache/tools/ant/taskdefs/XSLTProcess.java
>

main/org/apache/tools/ant/taskdefs/optional/junit/AggregateTransformer.java
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Reply via email to