Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 49332 invoked from network); 29 Nov 2002 07:19:09 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 29 Nov 2002 07:19:09 -0000 Received: (qmail 10855 invoked by uid 97); 29 Nov 2002 07:20:21 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 10824 invoked by uid 97); 29 Nov 2002 07:20:21 -0000 Mailing-List: contact ant-dev-help@jakarta.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 ant-dev@jakarta.apache.org Received: (qmail 10812 invoked by uid 98); 29 Nov 2002 07:20:20 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) X-Authentication-Warning: bodewig.bost.de: bodewig set sender to bodewig@apache.org using -f To: ant-dev@jakarta.apache.org Subject: Re: PROPOSAL: top level execution order References: From: Stefan Bodewig Date: 29 Nov 2002 08:19:13 +0100 In-Reply-To: Message-ID: Lines: 39 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Military Intelligence) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Thu, 28 Nov 2002, Costin Manolache wrote: > Ok. Let me summarize the options: > > 1. Top-level gets executed _after_ xml processing, as part of > resolving dependencies. That's the current HEAD > > 2. Top-level gets executed as part of xml processing and _before_ > resolving dependencies. ( the current EMBED ). > > 3. Same as 2, but each top-level element gets executed imediately > after it is read. > > In 1 and 2 - we agree that delayed construction of tasks is required > in order to support redefinition of core tasks. Right. And it would be in 3 as well to work for s inside of s. So the problem of replacing built-in tasks is not related to the top level execution order at all 8-) > A side effect is cleaner and more consistent code in the xml > processor Exactly. I think we all agree upon that, the only problem that may arise are some difficult to track backwards incompatibilities we must guard against. If we switch to delayed construction (or lazy evaluation or whatever you want to call it) and the testcase RhinoScriptTest passes - we are pretty save, I guess. This test just reproduces the examples from