ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: RV: Nesting Tasks
Date Fri, 14 Jul 2000 15:40:39 GMT
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 <> 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 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];

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

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.



View raw message