ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: PROPOSAL: top level execution order
Date Wed, 27 Nov 2002 15:32:38 GMT
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 ). If something relies on taskdef beeing
executed imediately, then it's a bug since we have no guarantee on
that ( the taskdef at top level will execute the same as a taskdef in a 
target ). That's if we're talking about the same thing :-)

> On Tue, 26 Nov 2002, Costin Manolache <> wrote:
>> The downside is that if tasks like <echo> or <javac> are used at top
>> level, they will be executed when -projecthelp is called.
> 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. Parser errors in imported files - yes, but the same would happen
if <ant> task is used. Non-XML errors and validation - yes, but that's
exactly what can happen today in many cases. 

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

>> Unfortunately it is not possible to implement -projecthelp
>> and also allow <javac> _and_ allow import in a clean way.
> Not that I'd like any of the solutions too much:
> * 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 ? ).
> * implement <import> by something that is not a task.

The reasons for import as a task: 
- simpler project helper ( it avoids complexity in a very tricky area)
- cleaner implementation (IMO)

Import is just one particular case - a whole class of tasks that operate
on the project tree will be possible.

>> The only solution is to document this and explain the
>> behavior
> Third option, and probably the one I like most.  But I still want to
> wait a few days to see whether anybody finds yet another solution to
> make that a fully supported +1.
>> Stefan - can you live with the top-level processing in embed ?
> My opinion is not that important, just one of a whole bunch of
> committers.

Every opinion is important. 


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message