ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Uther <will+...@cs.cmu.edu>
Subject ANT's strange semantics and proposed change
Date Fri, 25 Feb 2000 06:15:24 GMT
Hi,
  As I've already mentioned twice now, I'd like to create a task of the
form:

<ForEach variable="i" list="subprojectA:subprojectB" separator=":">
	<Ant dir="${i}" target="clean" />
	<Ant dir="${i}" target="main" />
</ForEach>

I just posted the patches neccessary to get tasks within other tasks.  This
type of looping task is still not possible though, and the problem is the
way ANT sets, initializes and executes tasks.

Currently each task is created, attributes set and init()ed in the order
listed in the build file.  After this has occurred, the set of targets is
topologically sorted and the targets required for the specified target are
executed in reverse topological order.

This means that properties get set in static order, not dynamic order (even
between targets).  This means that the execute() method of a task cannot
change the value of an attribute of another task.  The property command
sets properties in its init() method for just this reason.  If the Property
Task set properties in its execute method then all the other tasks would
already have their attributes set.

To see this in action, rename the "init" target of your ant build.xml to
"myinit" (the "init" target is treated specially).  Now move this target to
the end of the build file.  Finally add this special target to all the
other target's dependancy lists.  Given that this target is in all the
other target's dependancy lists you would expect it to execute first and
set all the properties correctly.  What you will actually see is that none
of the properties will be set correctly.  This is because the "myinit"
target is last in the build file.

Is there a reason for this strange semantics?

I suggest a new way of handling things:

ProjectHelper only instantiates targets.  Each target simply holds a
pointer to its DOM object without actually building all the tasks.

When a target is executed it builds the enclosed tasks one at a time, sets
their attributes and executes them.  Because each task is created, set and
executed in order there is no reason to have an init() method where
properties are set.  They can be set in the execute() method and they will
change the attributes of future tasks.

Thoughts, comments?

\x/ill            :-}



Mime
View raw message