Return-Path: Delivered-To: apmail-ant-dev-archive@www.apache.org Received: (qmail 32074 invoked from network); 28 Jun 2005 13:24:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 28 Jun 2005 13:24:58 -0000 Received: (qmail 64347 invoked by uid 500); 28 Jun 2005 13:24:54 -0000 Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 64303 invoked by uid 500); 28 Jun 2005 13:24:54 -0000 Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list dev@ant.apache.org Received: (qmail 64290 invoked by uid 99); 28 Jun 2005 13:24:53 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Jun 2005 06:24:53 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [213.86.197.2] (HELO mail.volantis.com) (213.86.197.2) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Jun 2005 06:24:52 -0700 Received: squid 10.20.30.27 from 10.20.30.87 10.20.30.87 via HTTP with MS-WebStorage 6.0.6249 Received: from c-pweighill-smith.uk.volantis.com by squid; 28 Jun 2005 14:24:46 +0100 Subject: "Local" properties From: Phil Weighill Smith To: Ant Developers List Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Volantis Systems Ltd. Date: Tue, 28 Jun 2005 14:24:46 +0100 Message-Id: <1119965086.22319.34.camel@c-pweighill-smith.uk.volantis.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I was thinking about "local" properties, having read the discussions relating to these in the last few months. Perhaps we could introduce the concept of "property scopes" instead. The project would provide a standard "global" property scope by default. It would also provide the ability to push and pop new property scopes (i.e. manage a stack of scopes). When a property is defined it goes into the current property scope (unless specifically allowed to be set in the "global" scope; see my export concept below for an example). When looking up a property, the property is looked for in widening scope (i.e. from top to bottom of the scope stack) until it is found or we have traversed the stack of property scopes all the way up to the "global" scope and found nothing. We could then provide any or all of: * "" and "" tasks (not my favorite idea as these can be unbalanced, I prefer the following). * a "createPropertyScope" attribute on target and/or "sequential" and "parallel" tasks or a special "" task based on "sequential" * allow scopes to be automatically managed in macrodefs to avoid the need for special syntax for macro parameters (they can be properties in a new scope). * an "" task to promote a named property up one scope or into the global scope as required (understanding that export will not modify any existing property with the same name in the target scope; it might also be possible to provide a means of this exporting properties from a sub-ant execution to the calling ant execution...?). An alternative is to name scopes and allow export to promote a property to the named scope, with "default" or "global" being the name of the "global" (initial) scope. All existing behaviour (and therefore BC) can be retained through the Project API and the "default" settings for any new attributes introduced. What do people think? Phil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org