Return-Path: 
 <dev-return-75045-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@www.apache.org
Received: (qmail 30943 invoked from network); 21 Sep 2006 15:45:56 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 21 Sep 2006 15:45:56 -0000
Received: (qmail 11572 invoked by uid 500); 21 Sep 2006 15:45:54 -0000
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 11514 invoked by uid 500); 21 Sep 2006 15:45:54 -0000
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@ant.apache.org>
List-Help: <mailto:dev-help@ant.apache.org>
List-Post: <mailto:dev@ant.apache.org>
List-Id: "Ant Developers List" <dev.ant.apache.org>
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 11503 invoked by uid 99); 21 Sep 2006 15:45:54 -0000
Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org)
 (140.211.166.84)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Sep 2006 08:45:54 -0700
Authentication-Results: idunn.apache.osuosl.org smtp.mail=antoine@gmx.de;
 spf=pass
X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests=
Received-SPF: pass (idunn.apache.osuosl.org: domain gmx.de designates
 213.165.64.20 as permitted sender)
Received: from [213.165.64.20] ([213.165.64.20:48978] helo=mail.gmx.net)
	by idunn.apache.osuosl.org (ecelerity 2.1.1.8 r(12930)) with ESMTP
	id 8E/10-01605-DA3B2154 for <dev@ant.apache.org>;
 Thu, 21 Sep 2006 08:45:50 -0700
Received: (qmail 4636 invoked by uid 0); 21 Sep 2006 15:45:47 -0000
Received: from 66.28.87.10 by www090.gmx.net with HTTP;
 Thu, 21 Sep 2006 17:45:46 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 21 Sep 2006 17:45:46 +0200
From: "Antoine Levy-Lambert" <antoine@gmx.de>
In-Reply-To: <255d8d690609210706x6807c3edycaec3206b2f0750a@mail.gmail.com>
Message-ID: <20060921154546.48630@gmx.net>
MIME-Version: 1.0
References: <20060920145752.33304.qmail@web55107.mail.re4.yahoo.com>	
 <87k63xltxb.fsf@www.samaflost.de> <451256A0.1080806@apache.org>	
 <20060921130249.294630@gmx.net> <4512905D.3040307@apache.org>
 <255d8d690609210706x6807c3edycaec3206b2f0750a@mail.gmail.com>
Subject: Re: Resource.getURL()
To: "Ant Developers List" <dev@ant.apache.org>
X-Authenticated: #22961642
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
Content-Transfer-Encoding: 7bit
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

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
-------- Original-Nachricht --------
Datum: Thu, 21 Sep 2006 09:06:23 -0500
Von: "Dominique Devienne" <ddevienne@gmail.com>
An: "Ant Developers List" <dev@ant.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 <import> came 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 UOE 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. --DD
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org