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
:12:51 AM
Subject: Re: Resource.getURL() - example
On 9/29/06, Matt Benson <[EMAIL PROTECTED]> wrote:
>
> FYI all, this AM I did think of another point which heavily favors
> application-level resolution: we have already set a precedent for this with
> our handling of the antl
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: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> > Sent: Wednes
14 matches
Mail list logo