ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Ant2 and <script>
Date Fri, 15 Dec 2000 15:24:15 GMT
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

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 -

(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.


View raw message