Hi Carlos,
if nobody has responded yet, this is not due to our ignorance but
because many of us are quite busy at the moment.
>>>>> "CP" == Carlos Pita <[EMAIL PROTECTED]> writes:
CP> I'm waiting my proposal not to be plainly rejected to begin
CP> writing it (I don't want to have my own ant branch :( ).
Of course.
OK, let's see. I'm not too fond of a looping construct actually as I
feel this is putting too much procedural behavior into Ant.
As you are proposing to do it on a task level and not inside the Ant
core, this might be "tolerable" (tongue in the cheek smiley here), but
before I take a closer look at what you are proposing, consider
<target name="inside_loop" id="inner">
<mkdir id="mkdir1" />
<copydir id="copydir1" />
</target>
<target name="loop" />
<script language="JavaScript"><![CDATA[
targetDir[0] = "myfirstdir";
targetDir[1] = "myseconddir";
copydir1.src = "mysourcedir";
for (i=0; i<2; i++) {
mkdir1.dir = targetDir[i];
copydir1.dest = targetDir[i];
inner.execute();
}
]]></script>
</target>
This might not be the exact syntax but you get the idea. And something
like this is already available, at least partly and it will be
extended.
But now to your proposal.
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
