>>>>> "mf" == mpfoemme <[EMAIL PROTECTED]> writes:
mf> What if we allow all tasks (as opposed to just properties and mf> taskdefs) to be used outside of targets , and execute them on the mf> spot? I agree with Sam that this would remove the special case we have for properties and taskdefs but actually would prefer it the other way around. My proposal: 1. Don't treat properties as tasks at all. Don't even say they are tasks in the documentation. 2. Do the same for taskdefs. 3. Don't instantiate tasks before they get executed. 4. Merge init and execute into a single method that gets called right after the task has been configured. This should enable the late compilation of tasks and remove some of the darker sides of Ant (the "weird behavior of available" for example) at the same time. The only tricky thing in this is part 3. One solution would be to revert to a DOM tree and defer parsing of the tree part below targets until the target gets executed. Neither too difficult nor elegant. Another solution would be the proxy pattern Sam suggested a while back. Configure a proxy object for the task at parse time and that again instantiates, configures and executes the task when it's time to get the work done. This latter solution might even have the additional power to choose between several special implementations of a generic task (choose between classic/modern javac or jikes or ..., choose the vendor implementation of idl2java, sqlj or similar things) like Valentin suggested. I'm not sure how to implement this easily without having to modify all existing tasks though. The only drawback I can see is that errors like misspelled attribute names in the build.xml won't get caught before the task gets executed as the proxies would need to accept all attributes. Comments? Stefan
