Wed, 20 Sep 2006, Matt Benson <gudnabrsam (AT) yahoo (DOT) comwrote:
Antoine Levy-Lambert <antoine (AT) gmx (DOT) dewrote:

>Hello Matt,
>
>thanks for fixing my fixes !
>
>did you already add getURL() to all Resource(s) ?
>this would be cool to be able to always set the
>SystemId in case of XML documents of all sorts.
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 any.
Given that Resource as a class and not an interface we are able to add
new methods even after 1.7.0 without running the risk of breaking the
code of people who implement their own resources. Given that there
wouldn't be any code in Ant 1.7.0 that used getURL() we should defer
adding the method as well, IMH
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?
+1 for custom protocol handlers.
Stefan
To unsubscribe, e-mail: dev-unsubscribe (AT) ant (DOT) apache.org
For additional commands, e-mail: dev-help (AT) ant (DOT) apache.org

Stefan Bodewig wrote:
Wed, 20 Sep 2006, Matt Benson <gudnabrsam (AT) yahoo (DOT) comwrote:
>Antoine Levy-Lambert <antoine (AT) gmx (DOT) dewrote:
>>
Hello Matt,

thanks for fixing my fixes !

did you already add getURL() to all Resource(s) ?
this would be cool to be able to always set the
SystemId in case of XML documents of all sorts.
>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 any.

Given that Resource as a class and not an interface we are able to add
new methods even after 1.7.0 without running the risk of breaking the
code of people who implement their own resources. Given that there
wouldn't be any code in Ant 1.7.0 that used getURL() we should defer
adding the method as well, IMH

maybe, but if a subclass adds its own getURL() method bad things happen.
Also, if subclasses ought to override it, then we dont give ant1.7-based
resources a warking.


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

+1 for custom protocol handlers.

Its very hard to add custom protocol handlers in java once you have a
classloader tree. and you increase the effort needed to implement a
resource.

How about having a hasURL interface that resources can implement? That
way things like my <randomcomponent dont need to bother.?

To unsubscribe, e-mail: dev-unsubscribe (AT) ant (DOT) apache.org
For additional commands, e-mail: dev-help (AT) ant (DOT) apache.org

Hi,

I would like to add getURL() to Resource before Ant 1.7 ships.

I would add it to the Resource base class, and to ZipResource, FileResource.

I am not clear whether it is better to signal that a particular Resource does not provide URL by throwing UException (as Matt suggested) or by returning null.

Concerning custom URLProtocolHandler (s), I am not clear how this works ?

Regards,

Antoine
Nachricht
Datum: Thu, 21 Sep 2006 10:08:48 +0100
Von: Steve Loughran <stevel (AT) apache (DOT) org>
An: Ant Developers List <dev (AT) ant (DOT) apache.org>
Betreff: Re: Resource.getURL()

Stefan Bodewig wrote:
Wed, 20 Sep 2006, Matt Benson <gudnabrsam (AT) yahoo (DOT) comwrote:
>Antoine Levy-Lambert <antoine (AT) gmx (DOT) dewrote:
>>
Hello Matt,

thanks for fixing my fixes !

did you already add getURL() to all Resource(s) ?
this would be cool to be able to always set the
SystemId in case of XML documents of all sorts.
>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 any.

Given that Resource as a class and not an interface we are able to add
new methods even after 1.7.0 without running the risk of breaking the
code of people who implement their own resources. Given that there
wouldn't be any code in Ant 1.7.0 that used getURL() we should defer
adding the method as well, IMH

maybe, but if a subclass adds its own getURL() method bad things happen.
Also, if subclasses ought to override it, then we dont give ant1.7-based
resources a warking.


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

+1 for custom protocol handlers.

Its very hard to add custom protocol handlers in java once you have a
classloader tree. and you increase the effort needed to implement a
resource.

How about having a hasURL interface that resources can implement? That
way things like my <randomcomponent dont need to bother.?

To unsubscribe, e-mail: dev-unsubscribe (AT) ant (DOT) apache.org
For additional commands, e-mail: dev-help (AT) ant (DOT) apache.org

Antoine Levy-Lambert wrote:
Hi,

I would like to add getURL() to Resource before Ant 1.7 ships.

I would add it to the Resource base class, and to ZipResource, FileResource.

I am not clear whether it is better to signal that a particular Resource does not provide URL by throwing UException (as Matt suggested) or by returning null.

Concerning custom URLProtocolHandler (s), I am not clear how this works ?

first you provide something that lets you open connections

and connections should be openable, or, as in this case, tell you off
for trying to do so

The real problem is that to use URLs with URL.openConnection() you need
to register the protocol in the top classloader, or the URL class
cannot open them. The alternative is to have a method in some class,
openConnection(URL), which looks through its list of registered handlers
and picks the right one:

To summarise: If you are going to play with URLs, you are going to
discover problems with classloaders

dont say I didnt warn you
-steve

To unsubscribe, e-mail: dev-unsubscribe (AT) ant (DOT) apache.org
For additional commands, e-mail: dev-help (AT) ant (DOT) apache.org

Concerning custom URLProtocolHandler (s), I am not clear how this works ?
first you provide something that lets you open connections []

FTR, I'm not to fond of this idea of playing with custom URL protocols
and/or handlers, at least as far as I correctly understood what it
means.

I used to use one before <importcame along, using a resource:
protocol to locate XML entity includes more flexibly, and it worked
fine, except for the fact that it needed JVM args required during JVM
startup. Installing the custom URL handler once the VM is already
started is more involved, and if I remember correctly, involves having
one's own factory for URL handlers, which is bound to conflict with
Ant "containers" who also want to install their own.

I think when Resources where first introduced to Ant we briefly
discussed why we needed them instead of using straight URLs, which is
a well documented and extensible mechanism to access content, but an
argument against using URLs was that extending URL protocols is not
easy.

I'm fine with adding getURL to Resources, if it's an optional
operation (returning null is not supported or throwing UE but only is
another supportsURL() boolean method is available), but I can't see
the need for custom URL protocols. I'm open to arguments showing me
where I'm wrong though, of course.

To unsubscribe, e-mail: dev-unsubscribe (AT) ant (DOT) apache.org
For additional commands, e-mail: dev-help (AT) ant (DOT) apache.org

Hello Dominique,

in this case I would add getURL() to Resource, returning null,
and getURL() to FileResource returning file:// and getURL() to ZipResource returning jar:file:// .

Concerning the custom handlers, I will not do anything. This will be left to the developers of custom resource implementations.

Regards,

Antoine
Nachricht
Datum: Thu, 21 Sep 2006 09:06:23 -0500
Von: "Dominique Devienne" <ddevienne (AT) gmail (DOT) com>
An: "Ant Developers List" <dev (AT) ant (DOT) apache.org>
Betreff: Re: Resource.getURL()

Concerning custom URLProtocolHandler (s), I am not clear how this
works ?
first you provide something that lets you open connections []

FTR, I'm not to fond of this idea of playing with custom URL protocols
and/or handlers, at least as far as I correctly understood what it
means.

I used to use one before <importcame along, using a resource:
protocol to locate XML entity includes more flexibly, and it worked
fine, except for the fact that it needed JVM args required during JVM
startup. Installing the custom URL handler once the VM is already
started is more involved, and if I remember correctly, involves having
one's own factory for URL handlers, which is bound to conflict with
Ant "containers" who also want to install their own.

I think when Resources where first introduced to Ant we briefly
discussed why we needed them instead of using straight URLs, which is
a well documented and extensible mechanism to access content, but an
argument against using URLs was that extending URL protocols is not
easy.

I'm fine with adding getURL to Resources, if it's an optional
operation (returning null is not supported or throwing UE but only is
another supportsURL() boolean method is available), but I can't see
the need for custom URL protocols. I'm open to arguments showing me
where I'm wrong though, of course.

To unsubscribe, e-mail: dev-unsubscribe (AT) ant (DOT) apache.org
For additional commands, e-mail: dev-help (AT) ant (DOT) apache.org