Return-Path: 
 <dev-return-61229-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@www.apache.org
Received: (qmail 73748 invoked from network); 29 Oct 2004 17:42:06 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 29 Oct 2004 17:42:06 -0000
Received: (qmail 18717 invoked by uid 500); 29 Oct 2004 17:41:31 -0000
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 18556 invoked by uid 500); 29 Oct 2004 17:41:30 -0000
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@ant.apache.org>
List-Subscribe: <mailto:dev-subscribe@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 18422 invoked by uid 99); 29 Oct 2004 17:41:28 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=NO_REAL_NAME
X-Spam-Check-By: apache.org
Received: from [192.18.33.10] (HELO exchange.sun.com) (192.18.33.10)
  by apache.org (qpsmtpd/0.28) with SMTP; Fri, 29 Oct 2004 10:41:27 -0700
Received: (qmail 22213 invoked by uid 50); 29 Oct 2004 17:43:32 -0000
Date: 29 Oct 2004 17:43:32 -0000
Message-ID: <20041029174332.22212.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: dev@ant.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 31947]  -
    War task should flatten files in <lib> element
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31947>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31947

War task should flatten files in <lib> element





------- Additional Comments From j_a_fernandez@yahoo.com  2004-10-29 17:43 -------
What do you mean, that the files returned by the <fileset> will say they are 
in one place but they are actually comming from a different place? So when I 
find an error in some file, the class will write the wrong location because it 
thinks it is in a place where it is not?

Such thing will break 90% of the tasks that use <fileset>s. Most tasks do 
their own mapping given by its own rules (like javac). You cannt just change 
them any way you want and not expect concequences.

But I could agreed that we should have a more centralized concept for things 
that do read/write. Today read is expressed by <fileset> and write by <mapper>.
Much more tasks should support these two.

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