Both Myrmidon and AntEater instantiate tasks at execution time, unlike Ant 1.x. This will have some impact on what you can do with scripts.
Then both proposals don't have a execute method in target anymore, this will limit scripts further - but this shouldn't be a big deal as execute could simply invoke project.executeTarget(getName()) and we'd be done - guess this is against the IOC pattern, Pete. AntEater doesn't have an executeTarget yet, but will sure get something similar once it cares for dependencies. If you take a look at the two examples in the Ant documentation, neither of both would work in Myrmidon or AntEater. The problems for Example 1: It is no longer Project that creates task instances - no big deal, both proposals have factories for this, just make them available to scripts as well. The second point is that Target doesn't know how to deal with complete task instances - in both proposals Target has become a store for task placeholders not for real tasks. Likewise, when the targets get executed, project doesn't know how to deal with already configured tasks. The problems for Example 2: There is no instance of an Echo task theEcho at all when the scripts get executed. In AntEater we'd have a Task and maybe giving it a setAttribute(String name, Object value) could help us here. In Myrmidon we'd have a Configuration Object, that we could use to set the attribute. Anyway, we'd be accessing placeholders here - no tasks. We lose the simple bean pattern that could allow us to write theEcho.message = "message" And then there might be scripts - valid in Ant 1.x - that invoke Task.execute directly. No way to do this in one of the two proposals. To summarize: (1) Target doesn't have an execute method - could and should be changed IMHO. (2) Scripts don't have access to the factory that creates tasks - dito. (3) There is no way to add a completely configured task to a target and execute that target after that. There are two options around that (a) don't allow a script to instantiate a task directly but make it create a placeholder instead (b) build special cases into Target and Project to deal either with placeholders or with concrete tasks. Not sure which I'd prefer. (4) Scripts cannot access attributes of tasks defined in the same build file. Possible workaround is to add generic getAttribute/setAttribute methods to the placeholders. (5) Scripts cannot execute tasks. Hmm, we could provide some Project.executeTask(placeholder) method. I'd be willing to drop (4) and (5) completely, while we should take care of (1), (2) and (3). If we chose solution (3a) we'd have to solve (4) as well. Stefan
