Return-Path: 
 <ant-dev-return-39917-qmlist-jakarta-archive-ant-dev=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@apache.org
Received: (qmail 43175 invoked from network); 27 Nov 2002 17:19:56 -0000
Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131)
  by daedalus.apache.org with SMTP; 27 Nov 2002 17:19:56 -0000
Received: (qmail 7710 invoked by uid 97); 27 Nov 2002 17:20:57 -0000
Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org
Received: (qmail 7679 invoked by uid 97); 27 Nov 2002 17:20:57 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:ant-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:ant-dev-help@jakarta.apache.org>
List-Post: <mailto:ant-dev@jakarta.apache.org>
List-Id: "Ant Developers List" <ant-dev.jakarta.apache.org>
Reply-To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 7663 invoked by uid 98); 27 Nov 2002 17:20:56 -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: <as0rsu$lmq$1@main.gmane.org> <m31y57s5dx.fsf@bodewig.bost.de>
	<as2oeu$t0j$1@main.gmane.org>
From: Stefan Bodewig <bodewig@apache.org>
Date: 27 Nov 2002 18:19:48 +0100
In-Reply-To: <as2oeu$t0j$1@main.gmane.org>
Message-ID: <m3lm3fnd57.fsf@bodewig.bost.de>
Lines: 59
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 Wed, 27 Nov 2002, Costin Manolache <cmanolache@yahoo.com> wrote:
> Stefan Bodewig wrote:
> 
>> Another downside of the HEAD version: As I pointed out last week,
>> the way CVS HEAD works breaks backwards compatibilty in a subtle
>> way because <taskdef>s will no longer be executed before the task
>> definitions are encountered by the parser right now.
> 
> That's an upside IMO :-)
> 
> It will lead to more consistent behavior ( especially if combined
> with the generalised lazy eval ).

Quite the opposite - see Conor's example of replacing echo with jar.
It works in 1.5.1 and doesn't in CVS HEAD.  If you put the taskdef
into a target, only the first <echo> is going to work, but not the
second (in both Ants).

So yes, CVS HEAD is more consistent that it breaks in both situations,
but it shouldn't break at all (or at least be consistent in not
allowing the no-child version of echo either).

> If something relies on taskdef beeing executed imediately, then it's
> a bug

good bye replacement of built-in tasks ...

> since we have no guarantee on that

"It's always been that way since <taskdef> has been introduced"
doesn't count?

>> And when the parser detects an error after some of the tasks have
>> been run ...
> 
> Parser ( XML ) errors will be detected in the same way in the main
> build file.

I was talking about the project file parser, not the XML parser.
Things like <target> nested into <target>.

> I agree - we'll introduce many new ways for users to hurt themself,
> but they never lacked that ability.

8-)

>> * marker interface for tasks to be run at parser time.
> 
> That's a possible solution - however the biggest limitation (IMO) is
> that users may _need_ to execute all kind of stuff ( url get, etc ?
> ).

I know - I said I wouldn't like it. ;-)

> Every opinion is important. 

This is what I wanted to say.

Stefan

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