Return-Path: 
 <dev-return-83689-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@www.apache.org
Received: (qmail 89191 invoked from network); 17 Nov 2008 12:27:09 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 17 Nov 2008 12:27:09 -0000
Received: (qmail 64941 invoked by uid 500); 17 Nov 2008 12:27:17 -0000
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 64892 invoked by uid 500); 17 Nov 2008 12:27:17 -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 64881 invoked by uid 99); 17 Nov 2008 12:27:17 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Nov 2008 04:27:17 -0800
X-ASF-Spam-Status: No, hits=1.2 required=10.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [88.84.142.181] (HELO samaflost.de) (88.84.142.181)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Nov 2008 12:25:56 +0000
Received: from localhost (unknown [127.0.0.1])
	by samaflost.de (Postfix) with ESMTP id 55A0DE220014
	for <dev@ant.apache.org>; Mon, 17 Nov 2008 12:26:40 +0000 (UTC)
Received: from samaflost.de ([127.0.0.1])
 by localhost (v30161.1blu.de [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 03898-02 for <dev@ant.apache.org>;
 Mon, 17 Nov 2008 13:26:38 +0100 (CET)
Received: by samaflost.de (Postfix, from userid 2525)
	id 50D96E22000A; Mon, 17 Nov 2008 13:26:38 +0100 (CET)
To: dev@ant.apache.org
Subject: Re: svn commit: r714053 -
 /ant/core/trunk/src/main/org/apache/tools/ant/types/resources/MappedResource.java
X-Draft-From: ("nnfolder:mail.jakarta-ant" 90891)
References: <20081114160431.88747238889C@eris.apache.org>
	<y1uvduqgtk0.fsf@v30161.1blu.de>
	<F18B1657-6F73-43F0-92D1-AE2AF4BFBC96@hibnet.org>
	<y1uskpqzspo.fsf@v30161.1blu.de> <49215032.9010809@hibnet.org>
From: Stefan Bodewig <bodewig@apache.org>
Date: Mon, 17 Nov 2008 13:26:38 +0100
In-Reply-To: <49215032.9010809@hibnet.org> ("Nicolas =?iso-8859-1?Q?Lalev?=
 =?iso-8859-1?Q?=E9e=22's?= message of "Mon\, 17 Nov 2008 12\:06\:26 +0100")
Message-ID: <y1ufxlqzgg1.fsf@v30161.1blu.de>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: amavisd-new at samaflost.de
X-Virus-Checked: Checked by ClamAV on apache.org

On 2008-11-17, Nicolas Lalev�e <nicolas.lalevee@hibnet.org> wrote:

> Stefan Bodewig a �crit :
>> On 2008-11-14, Nicolas Lalev�e <nicolas.lalevee@hibnet.org> wrote:


>>> But I see another solution, quite different. Probably most of the work
>>> should be done in the Resource class:

>> I thought about that, but Resource is already doing way too much IMHO.

> Well, in fact here you want a functionality to Resource (AFAIU).

No.

In the end what I want is a real decorator that attaches mapping on
top of an existing resource collection.  Something that allows people
to write

<war ...
  <mappedresource>
    <path refid="some-path"/>
    <chainedmapper>
      <flattenmapper/>
      <globmapper from="*" to="WEB-INF/lib/*"/>
    </chainedmapper>
  </mappedresource>
</war>

to package up all jars from nan arbitrary path into a WAR's lib
directory.

This really is pure decoration and not a functionality of the
resources involved.

> If you choose the former solution, then each time you want to add
> another implementation of Resource with some new capability, you will
> have to support it in MappedResource.

MappedResource now delegates on the as() (what is getAdapter() in
Eclipse) on to the decorated resource, no reason to support any of the
exiting interfaces.

> By the way, what about the Resource implementation in some ant
> plugins ? Is the Resource API exported ?

Yes.

> Wouldn't the former solution break some ant plugin ?

I lost track what "the former" was.  I do expect that people are doing
instanceof checks on FileProvider (or more likely on FileResource -
but then we are out of luck anyway), that's why I kept the
FileProvider implementing subclass.

Appendable is new and the use cases I see for MappedResource make it
unlikely that you'd use it in a context where Touchable makes sense.

Stefan

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