ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Task proxies (was Re: [GUMP] Build Failure - Fop)
Date Fri, 14 Dec 2001 08:50:10 GMT
On Fri, 14 Dec 2001, Jose Alberto Fernandez <>

> I can't try it right now, but do you mean <script/> is broken too?
> :-)

The example refers to a task by id and calls a method on it that
wouldn't exist in an UnknownElement.

> We have had UnknownElement for a long time, so you would think
> <script> should be able to deal with them at this point.

It's not only <script>.  It affects all things that may want to access
tasks by id.  When you replace the real tasks instances with
placeholders until they actually get "used", any call to
Project.getReferences and the newer Project.getReference has to be
assumed such a "use" as well.

The other thing that you lose is "early failure", i.e. we cannot tell
people that a given child element is invalid at parser time, which
means the build is halfway done when we reach the point of syntax
error.  That is you get a runtime error instead of a compilation
error, that could have been detected (in the absence of user taskdefs
which probably is the majority of build files).

The way we do it right now doesn't really work either as the built-in
task definition will be used to evaluate child elements instead of the
user's definition when the taskdef is nested into a target.

What I've been trying ATM:

* Project keeps track of all tasks that have been created for a given

* If the definition of that taskname changes, tell all the tasks that
they are no longer valid 

* Make invalidated tasks replace themselves with UnknownElements,
which in turn would create the correct task instances when
maybeConfigure gets called.

this is clumsy, I know.

The alternative is to go the "instantiate late and use proxies in all
other cases" approach just now and "de-proxy" tasks that are inside
the references hashtable as soon as something access this table.
Losing parser time validation of the build file at the same time.

> Otherwise, we are saying we cannot add any new tasks to ANT,

Like I said, unless we fix the problem, which is possible IMHO.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message