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 <dev@ant.apache.org> Sent: Friday, September 29, 2006 10: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 antlib: pseudo-protocol. Spring also does application-level resolution: 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 <dev@ant.apache.org> > 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 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 flag, but I > > will step aside. > > I feel like I am ignorant of what's really going on > > in your builds. > > I've worked some pretty hairy cross-repository > > builds in commercial > > systems. I've never needed to resort to custom > > protocol handlers, so I > > obviously don't know something about your situation > > that you do. Fair > > enough. > [SNIP] > > > > I have to look into Depot. Like I said, I think I'll > > step aside and > > let the discussion open up for others to give input. > > As the opener of this can of worms I welcome all > input. My situation: it is my opinion that Ant needs > a solution here. I am working on the assumption no > committer would -1 me on this point. That > accomplished, it seems that the custom protocol > handler idea and the application-level pseudo-protocol > idea are the two possibilities at hand. I still know > fairly little about the former; the latter is fairly > straightforward. As far as I know I am the originator > of both suggestions in the context of resolving an Ant > resource from a string representation. Given my lack > of expertise on the protocol-based approach and the > apparent "depth" of that solution, I solicited the > opinions of others. The apparent results so far: > > protocol-based approach: > -tricky to get installed smoothly and correctly > -no Ant developer knowledge, but possibly Stephen M. > is willing to guide us where we stumble? > -standard (for better or worse); therefore possibly > applicable to more situations AND preexisting > protocols may be easier to adapt to Ant. > -seen by some as "too much"? (is that a fair > paraphrase of your feelings, Scott?) > > application-level approach: > -3rd-party impls still require some sort of > Ant-specific registration > -resolution is fairly straightforward > -solution only applies to whatever situations we > explicitly provide for. > > 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 decision on this fairly soon before > this thread runs out of steam and we have to do it all > over again (voice of experience). What are the other > committers' feelings at this point? > > TIA, > Matt > > > > > Best regards, > > Scott Stirling > > Framingham, MA > > > > > --------------------------------------------------------------------- > > 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] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
