Looking at options that have been put forward following Matt's request for
comment it seems to me that the actual requirements are still too loose.
However - I do think we can break down some different topics:
1. namespaced resources
the support within Ant for named resources associate
On Thu, 28 Sep 2006, Matt Benson <[EMAIL PROTECTED]> wrote:
> My current impression is that, partially contingent on
> Stephen's willingness to field questions, ;) the
> protocol-based solution is preferable, or at least
> worth _proving_ unsuitable. In any event, I'd like
> for us to reach a dec
> -Original Message-
> From: Steve Loughran [mailto:[EMAIL PROTECTED]
> If we retrofit stuff into Java, with Java URL handling, then
> some URL like a reference to a file on the classpath, it
> would have to be turned into a string that included a
> classloader reference:
>
> class
> -Original Message-
> From: Scott Stirling [mailto:[EMAIL PROTECTED]
> But when you encapsulate artifact location resolution into
> Java protocol handlers (which is what I think you're doing),
> you've made the build into something that, while, OK, not a
> black box, requires an un
Good point; I don't have to follow your link... I use "classpath:..." often
enough. :) I must admit to having partaken of the Spring kool-aid...
- Original Message
From: Peter Reilly <[EMAIL PROTECTED]>
To: Ant Developers List
Sent: Friday, September 29, 2006 10
n: see:
http://static.springframework.org/spring/docs/2.0.x/reference/resources.html
Peter
-Matt
- Original Message
From: Matt Benson <[EMAIL PROTECTED]>
To: Ant Developers List
Sent: Thursday, September 28, 2006 4:19:11 PM
Subject: Re: Resource.getURL() - example
--- Sc
Sent: Thursday, September 28, 2006 4:19:11 PM
Subject: Re: Resource.getURL() - example
--- Scott Stirling <[EMAIL PROTECTED]> wrote:
> On 9/28/06, Stephen McConnell <[EMAIL PROTECTED]>
> wrote:
> [...]
> > This difference in scope an example that
> demonstrates an a
Stephen McConnell wrote:
-Original Message-
From: Scott Stirling [mailto:[EMAIL PROTECTED]
[snip]
All of these protocols include support for the establishment of a
locally cached file that is a copy of the remote resource (partly
driven by the need to handle the relationship betw
> -Original Message-
> From: Matt Benson [mailto:[EMAIL PROTECTED]
> My current impression is that, partially contingent on
> Stephen's willingness to field questions, ;) the
> protocol-based solution is preferable, or at least
> worth _proving_ unsuitable.
Matt:
My schedule is free
--- Scott Stirling <[EMAIL PROTECTED]> wrote:
> On 9/28/06, Stephen McConnell <[EMAIL PROTECTED]>
> wrote:
> [...]
> > This difference in scope an example that
> demonstrates an area where existing
> > protocols and software are insufficient.
>
> OK, if you say so. In my experience the statement
On 9/28/06, Stephen McConnell <[EMAIL PROTECTED]> wrote:
[...]
This difference in scope an example that demonstrates an area where existing
protocols and software are insufficient.
OK, if you say so. In my experience the statement "existing protocols
and software are insufficient," is a red fla
> -Original Message-
> From: Scott Stirling [mailto:[EMAIL PROTECTED]
[snip]
> > > All of these protocols include support for the establishment of a
> > > locally cached file that is a copy of the remote resource (partly
> > > driven by the need to handle the relationship between mo
On 9/27/06, Stephen McConnell <[EMAIL PROTECTED]> wrote:
> I make extensive use of custom protocols to represent links
> to resources not contained within a particular project
> code-base. These protocols include the following:
>
> 'artifact' used to resolve resources from a collection
>
> -Original Message-
> From: Stephen McConnell [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 27 September 2006 4:58 PM
> To: 'Ant Developers List'
> Subject: RE: Resource.getURL()
>
>
>
> > -Original Message-
> > From: Ste
> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 27 September 2006 2:00 PM
> To: dev@ant.apache.org
> Subject: Re: Resource.getURL()
>
> On Tue, 26 Sep 2006, Stephen McConnell <[EMAIL PROTECTED]> wrote:
>
On Tue, 26 Sep 2006, Stephen McConnell <[EMAIL PROTECTED]> wrote:
> As such, some resource are implicitly file based (e.g. FileResource)
> while other resources may (or may not) be resolvable to a local
> file.
What kind of resources would that be?
> The important distinction here is that Path s
> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 26 September 2006 12:56 PM
> To: dev@ant.apache.org
> Subject: Re: Resource.getURL()
>
> On Tue, 26 Sep 2006, Stephen McConnell <[EMAIL PROTECTED]> wrote:
> >&
> -Original Message-
> From: Matt Benson [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 26 September 2006 6:28 AM
> To: Ant Developers List
> Subject: RE: Resource.getURL()
[snip]
> > Matt:
> >
> > Can you expand on what you mean by "a string repre
On Mon, 25 Sep 2006, Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:
>> URLResource (s) AFAIK do not have a special "root".
>
> I think they are considered as having a root concept;
You are both correct.
There are hierarchical and opaque URLs. opaqu
On Tue, 26 Sep 2006, Stephen McConnell <[EMAIL PROTECTED]> wrote:
>> From: Matt Benson [mailto:[EMAIL PROTECTED]
>> Path's inheritance hierarchy was altered such that its immediate
>> superclass is the new Union resource collection. So the only
>> difference between the two is, for all practical
--- Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:
> Hello Dominique,
>
> Dominique Devienne wrote:
> >>
> >> getURL() makes sense for FileResource and
> ZipResource too.
> >
> > Yes, but these can be expressed as URLResource
> just the same. Maybe
> > they should in fact derive from URLResource
--- Stephen McConnell <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: Matt Benson [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, 26 September 2006 4:17 AM
> > To: Ant Developers List
> > Subject: Re: Resource.getURL()
> &g
Hello Dominique,
Dominique Devienne wrote:
>>
>> getURL() makes sense for FileResource and ZipResource too.
>
> Yes, but these can be expressed as URLResource just the same. Maybe
> they should in fact derive from URLResource...
I do not agree with you on this. ZipResource and FileResource have t
> -Original Message-
> From: Matt Benson [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 26 September 2006 4:17 AM
> To: Ant Developers List
> Subject: Re: Resource.getURL()
>
> --- Dominique Devienne <[EMAIL PROTECTED]> wrote:
>
> > > A URLResource
> -Original Message-
> From: Matt Benson [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 26 September 2006 4:28 AM
> To: Ant Developers List
> Subject: RE: Resource.getURL()
>
> --- Stephen McConnell <[EMAIL PROTECTED]> wrote:
> [SNIP]
> >
> > S
--- Stephen McConnell <[EMAIL PROTECTED]> wrote:
[SNIP]
>
> Some thoughts after digging though Resource and
> associated classes ...
>
> Of particular interest to me is the ability to
> declare resources that can be
> used as arguments to a Path definition - however, as
> things currently stand
>
--- Stephen McConnell <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: Dominique Devienne
> [mailto:[EMAIL PROTECTED]
> > Sent: Monday, 25 September 2006 10:32 PM
> > To: Ant Developers List
> > Subject: Re: Resource.getURL
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > A URLResource could then be created using:
> > new URLResource( name, uri,
> handlerClassResourceName );
> >
> > The upside of this approach is the elimination of
> the entire subject of
> > system classloader mutation, and a framework for
> bi
> -Original Message-
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> Sent: Monday, 25 September 2006 10:32 PM
> To: Ant Developers List
> Subject: Re: Resource.getURL()
>
> > > The question is why would you need to get back a URL from
> > >
> This is the reason why I'm saying that a getURL only makes sense for
> true URLResources only.
getURL() makes sense for FileResource and ZipResource too.
Yes, but these can be expressed as URLResource just the same. Maybe
they should in fact derive from URLResource... This way, we could
differ
Hi,
Dominique Devienne wrote:
>> > The question is why would you need to get back a URL from a Resource?
>> You need to get a URL from a resource if you want to use the resource as
>> InputSource in XML processing.
>> The URL is used to set the SystemId, in practice to be able to resolve
>> inclu
> The question is why would you need to get back a URL from a Resource?
You need to get a URL from a resource if you want to use the resource as
InputSource in XML processing.
The URL is used to set the SystemId, in practice to be able to resolve
includes, entities, ... which are to be found with
A URLResource could then be created using:
new URLResource( name, uri, handlerClassResourceName );
The upside of this approach is the elimination of the entire subject of
system classloader mutation, and a framework for binding custom handlers
(which resolves some of the earlier issues raised in
Dominique Devienne wrote:
>
> The question is why would you need to get back a URL from a Resource?
You need to get a URL from a resource if you want to use the resource as
InputSource in XML processing.
The URL is used to set the SystemId, in practice to be able to resolve
includes, entities, ...
Scott Stirling wrote:
> Where would these protocols appear from a user perspective?
> In build scripts? If that's the case, then I'd definitely say
> consider letting Ant handle them and convert them to standard
> URLs through a registry mechanism perhaps like the custom
> task registry.
Domi
> -Original Message-
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> Sent: Monday, 25 September 2006 10:28 AM
> To: Ant Developers List
> Subject: Re: Resource.getURL()
>
> > > This surprises me. You're positive you can change the syste
> This surprises me. You're positive you can change the system's
> classloader classpath dynamically just by assigning to this property?
The system property 'java.system.class.loader' is used to declare the name
of custom system classloader class. [...]
But as I pointed out, this is a JRE 1.4
> -Original Message-
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> Sent: Sunday, 24 September 2006 1:27 AM
> To: Ant Developers List
> Subject: Re: Resource.getURL()
>
> > Actual mutation of the system classloader can be handled
> > with relati
Actual mutation of the system classloader can be handled with relative
safety in JRE 1.4 and later via a system property 'java.system.class.loader'
This is news to me Steven. This implies that the system classloader
would need to query this property to see if it changed any time it
attempts to l
> -Original Message-
> From: Scott Stirling [mailto:[EMAIL PROTECTED]
> Sent: Friday, 22 September 2006 11:58 PM
> To: Ant Developers List
> Subject: Re: Resource.getURL()
>
> DD asks:
> > > Does that play well with application containers that
&
Yes, exactly. Sorry, I missed that. Just re-joined the list after a
long absence. I've implemented "pseudo" or application-level protocol
handlers before to achieve the same goals as here (as I understand
them so far).
Scott S.
Scott, are you talking about something like option (b)
that I descr
--- Scott Stirling <[EMAIL PROTECTED]> wrote:
> DD asks:
> > > Does that play well with application containers
> that often embed Ant?
>
> Stephen McConnell replies, in part:
> > Something to keep in mind is that the creation of
> a URL is handled inside
> > the system classloader. As such when
DD asks:
> Does that play well with application containers that often embed Ant?
Stephen McConnell replies, in part:
Something to keep in mind is that the creation of a URL is handled inside
the system classloader. As such when the JVM attempts to locate handler
classes, it is limited to clas
> -Original Message-
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> Sent: Friday, 22 September 2006 11:44 AM
> To: Ant Developers List
> Subject: Re: Resource.getURL()
>
> > Just for reference I have quite a bit of experience working with
> > cus
Just for reference I have quite a bit of experience working with custom
protocol handlers.
OK, that's better than my casual experience with them. How do you
install them? What does it require in terms of JVM startup arguments?
Does that play well with application containers that often embed Ant?
> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: Friday, 22 September 2006 4:58 AM
> To: dev@ant.apache.org
> Subject: Re: Resource.getURL()
>
> On Thu, 21 Sep 2006, Matt Benson <[EMAIL PROTECTED]> wrote:
>
> > Okay,
On Thu, 21 Sep 2006, Matt Benson <[EMAIL PROTECTED]> wrote:
> Okay, I've never used the custom protocol handlers,
> only read about them. I have no problem taking the
> word of others that there may be difficulties;
Same here.
> Let me interject on that thought. Currently
> Resource.getInputSt
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > > 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
resource implementations.
Regards,
Antoine
Original-Nachricht
Datum: Thu, 21 Sep 2006 09:06:23 -0500
Von: "Dominique Devienne" <[EMAIL PROTECTED]>
An: "Ant Developers List"
Betreff: Re: Resource.getURL()
> > > Concerning custom URLProtocolHandler (
> 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
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 UnsupportedOper
suggested)
or by returning null.
Concerning custom URLProtocolHandler (s), I am not clear how this works ?
Regards,
Antoine
Original-Nachricht
Datum: Thu, 21 Sep 2006 10:08:48 +0100
Von: Steve Loughran <[EMAIL PROTECTED]>
An: Ant Developers List
Betreff: Re: Resource.
Stefan Bodewig wrote:
On Wed, 20 Sep 2006, Matt Benson <[EMAIL PROTECTED]> wrote:
--- Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:
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
Xavier Hanin wrote:
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 r
On Wed, 20 Sep 2006, Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:
>
>> 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
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
nonstanda
56 matches
Mail list logo
