From dev-return-61288-apmail-ant-dev-archive=ant.apache.org@ant.apache.org Tue Nov 02 22:34:50 2004 Return-Path: Delivered-To: apmail-ant-dev-archive@www.apache.org Received: (qmail 36417 invoked from network); 2 Nov 2004 22:34:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 2 Nov 2004 22:34:49 -0000 Received: (qmail 28164 invoked by uid 500); 2 Nov 2004 22:34:42 -0000 Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 28018 invoked by uid 500); 2 Nov 2004 22:34:40 -0000 Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list dev@ant.apache.org Received: (qmail 27882 invoked by uid 99); 2 Nov 2004 22:34:39 -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; Tue, 02 Nov 2004 14:34:38 -0800 Received: (qmail 29132 invoked by uid 50); 2 Nov 2004 22:34:36 -0000 Date: 2 Nov 2004 22:34:36 -0000 Message-ID: <20041102223436.29131.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: dev@ant.apache.org Cc: Subject: DO NOT REPLY [Bug 32006] - new optional 'basedir' attribute for property task 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 . 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=32006 new optional 'basedir' attribute for property task stevel@apache.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From stevel@apache.org 2004-11-02 22:34 ------- Ian, I am going to have to be ruthless and mark as wontfix. 1. you get exactly the semantics you want with (though you should *not* be hard coding paths into portable files) 2. changing the type of a setter for one of the core ant tasks is absolutely forbidden. That is the programmatic API to ant, and one that gets used a lot, especially by extension tasks. There may be no uses of that method in the ant codebase, but we don't know what other things use it, and have to assume the worst. You can overload an existing option, but then you have to deal with the existing one may still be called. 3. we have enough functionality stuck in that task already. What would the semantics be of setting basedir for any other operation? An error? Then we'd need the error checking code -and the tests that it worked. 4. If you do not find point #1 adequate, then the solution would be some explicit task to set a property to a bound dir: There may be some merit in that, as you can add more tests (base must exist, must be a dir, perhaps), and it may be more readable. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org