ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <james.david...@eng.sun.com>
Subject Re: [RFE] Richer Task Specification
Date Sun, 18 Jun 2000 08:14:59 GMT
on 6/14/00 11:59 AM, rubys@us.ibm.com at rubys@us.ibm.com wrote:

> This has me intrigued.  I do not believe it is as simple as moving this
> code from init to execute.  The trouble is that Ant constructs instances of
> all the tasks up front (calling init as it goes), then goes off and
> executes them.  Defering the taskdef to execute means that the new tasks
> will not be defined in time.

Though I should point out that the last time I worked on the core document,
this was tentatively changed to where task instance creation was something
that happened right before it was executed -- this was done to allow runtime
adjustment of properties and even the task tree by scripts (i.e. I was
thinking of you there!).

> An alternative would be to allow taskdefs to be deferred as an option.
> What that would do instead of creating the "real" task is to create a
> instance of a new class, say "proxyTask".  This task would be special and
> would simply accumulate the attributes, as well as being passed the name of
> the real task.  When it comes time to execute this task, it would attempt
> to create an instance of the real task, apply all the attributes, and
> finally invoke init followed by execute.

I don't think that it makes any difference internally to the task if it is
created before all tasks run, or right before it's run except as it helps
scripting affect the runtime task tree. I don't understand the use of a
proxyTask.... Or I guess more appropriatly, in the case described in the
core document, the task tree is whole representative and not literal. The
runtime reads the task set and creates instances as it goes.

.duncan


Mime
View raw message