ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: PROPOSAL: top level execution order
Date Mon, 02 Dec 2002 18:34:03 GMT
Stefan Bodewig wrote:

 >> 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 immediately
>> 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 <taskdef>s inside of
> <target>s.

Good point. The current solution is to replace the tasks ( at least
from what I understand in the code ), and it would be much cleaner to
use delayed construction of the task.

Ok, are we all in agreement on delayed construction of tasks ? Anyone
against ? If we agree, that should be the first thing to do.


> So the problem of replacing built-in tasks is not related to the top
> level execution order at all 8-)

+1

> 
>> 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
> <script>'s documentation that have been there since Ant 1.2 - we
> better don't break them 8-)

Ok, I'll try the Rhino test case with embed ( where delayed construction
is already implemented ), and let you know the result. If I can get it
to work then we can do it in the main branch.

> Oh, back to the subject, I'm leaning toward Option 3 from your list,
> but can live with 2 as well.

I would try 2 first, and keep 3 as a backup.

The pros and cons:
- with 2, the parser is just constructing a tree. The code is much simpler,
it is easier to remove SAX from the picture ( if someone wants to 
have ant operate on a DOM tree or have an application construct the tree
directly ). 

- also 2 is more consistent with what happens in targets, i.e. top level
is less "special".

On the other side:
- 3 is a closer to what we had before, so it's less danger on breaking 
backward compat ( that's why I would try 2 first, and if anything wrong
happens fallback to 3 ).

- 3 may be better for <import> - the import may happen immediately which is
cleaner ( with 2 the import will happen after the tree is constructed - 
and is more difficult to make the imported file replace the <import> ). 
However the opposite is true - import and similar tasks may work better
if they have access to the whole tree.

Another option would be to support both 2 and 3 - i.e. have tasks that
execute on read and tasks that execute normally. Since we don't want to 
instantiate the task until execution time - marker interfaces or special
methods won't work, but we can use a properties file with the list of 
'exec-on-load' tasks.
I would keep 2+3 as the last option.

Costin



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


Mime
View raw message