ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Ant2 and <script>
Date Sat, 16 Dec 2000 01:37:44 GMT
At 04:24  15/12/00 +0100, Stefan Bodewig wrote:
>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.


>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 

unfortunately yes. There is a possible method around this for specific
scripting engines. We *could* wrap the objects in a
IIRC Scriptable (or is it JS_Object ???) is the Rhino (Javascript engine)
way through we can customize interaction with objects. However this is
script-engine specific and non-portable ;(

>To summarize:
>(1) Target doesn't have an execute method - could and should be
>changed IMHO.

I am not sure I agree. Target can only be executed in the context of a
project (it doesn't make sense for independent execution of targets).
Myrmidon allows you to execute targets directly now by passing in contexts
- but you still need to get the context from somewhere (ie the project). So
I think the methods in ProjectEngine .. namely 

void execute( Project project, String target )
        throws AntException;

void execute( Project project, String target, TaskletContext context )
        throws AntException;

Should be sufficent ???

>(2) Scripts don't have access to the factory that creates tasks -

yep - we could make that accessble .. maybe. In most cases the individual
just wants to directly access the object - in which case there is no need
to go through an intermediate representation. In which case they can just go

FooTask foo = new FooTask();

For the few that this is not the case (ie the facades like execute and
javac) we should provide an engine I think ???

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

I would go 3a ;)

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

Already avaialable in mymidon .. except it is via 

TaskletEngine engine = ...;
engine.execute( taskPlaceHolder, context, componentManager );

(we could possibly exclude param 3).

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

I say we solve em all ;) (via 3a).



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

View raw message