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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
