Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@apache.org Received: (qmail 44152 invoked from network); 15 May 2002 04:14:47 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 15 May 2002 04:14:47 -0000 Received: (qmail 6 invoked by uid 97); 15 May 2002 04:14:49 -0000 Delivered-To: qmlist-jakarta-archive-ant-user@jakarta.apache.org Received: (qmail 29965 invoked by uid 97); 15 May 2002 04:14:48 -0000 Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Users List" Reply-To: "Ant Users List" Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 29953 invoked by uid 98); 15 May 2002 04:14:47 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) From: To: "Ant Users List" Subject: Re: Re[4]: The old immutable properties trick Date: Wed, 15 May 2002 14:14:42 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20020515041442.DKUD28392.mta06.mail.mel.aone.net.au@[127.0.0.1]> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N First in first served when it comes to defining a properties read-onlyness. That allows immutability when including existing buildfiles, and it allows any properties defined by the user to have the users choice of read-only or writeable. That only fair isn't it? If required you could even have an attribute required in the buildfile itself to allow overriding, defaulting to false for backwards compatability. It boils down to letting the buildfile author override properties if they see fit to. This message was sent through MyMail http://www.mymail.com.au -- To unsubscribe, e-mail: For additional commands, e-mail: