You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2000/12/15 16:24:15 UTC
Ant2 and
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
Re: Ant2 and
Posted by Peter Donald <do...@apache.org>.
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.
yep.
>If you take a look at the two examples in the Ant documentation,
>neither of both would work in Myrmidon or AntEater.
agreed.
>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
unfortunately yes. There is a possible method around this for specific
scripting engines. We *could* wrap the objects in a
pseudo-script-bean-objects.
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 -
>dito.
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).
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
Re: Ant2 and
Posted by James Duncan Davidson <du...@x180.net>.
On 12/15/00 7:24 AM, "Stefan Bodewig" <bo...@apache.org> wrote:
> 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.
Actually, the methodology hardly limits scripts. In fact it sets them free
as they can operate on the project tree at will.
> AntEater doesn't have an executeTarget yet, but will sure get
> something similar once it cares for dependencies.
Actually in the code that's checked in, it's "startBuild(String
targetName)", but it really should just be "buildTarget(String targetName)"
> 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.
Not yet in AntEater since Task isn't the task instance. However, there
should be.
--
James Duncan Davidson duncan@x180.net
!try; do()