ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlos Pita" <>
Subject RE: RV: Nesting Tasks
Date Fri, 14 Jul 2000 16:51:52 GMT
Hi again,

    There are no creator methods here. The sax handler for Tasks should find
out if the task is an instance of a NestingTask. If the Task is a nesting
one, each enclosed tag represents, in fact, a Task and not a NestedProperty,
so the thing to do here is the same that when a Target finds a Task tag.
When the task is initialized it adds itself to its enclosing Task's enclosed
Tasks list (if it has an enclosing Task), to its Target (as always),
....etc. If it is a normal Task, the algorithm follows the usual way
    Nesting Tasks only have a list A of nested Tasks, they don't provide any
kind of creators. They alse have a list B of Tasks that have properties to
be setted with the corresponding setter methods (this could be a hash
Tasks->setter_methods). Note that A and B could be different (and not
necesarily due B being a subset of A).

>  CP> 1) nesting Tasks are Tasks (actually subclasses of Task)
>  CP> 2) nesting Tasks can be nested by other nesting Tasks
> OK, no problem.
>  CP> 4) a nesting Task has a list with every enclosed (top-level)
>  CP> Task. (it could, for example, cycle over this list).
> Everything nested inside a nesting task would be created by a
> createNameThatTask() method or added to the nesting task via
> addNameThatTask(Task), so it would know about these of course.
> I see a mayor problem here, either nesting task would need to know all
> tasks by name (and provide methods to create or add them) - which is
> impossible in the light of taskdefs - or we would need to change the
> Ant core to support this.
>  CP> 3) nesting Tasks have a special (xml) property which lists a
>  CP> number of (ant) properties which wouldn't be expanded the normal
>  CP> way in the enclosed tags but instead will be expanded when
>  CP> execute'ing the nesting Task with a special subclass method (see
>  CP> below).
> Here you are proposing some heavier changes to the core - currently
> ProjectHelper doesn't care about whose attributes it is working on
> when expanding properties and so on. I'll have to think about the
> consequences before I can comment on it, sorry.
> Cheers
>         Stefan

View raw message