Task proxies (was Re: [GUMP] Build Failure - Fop)

[Stefan Bodewig <bo...@apache.org>]

On Fri, 14 Dec 2001, Jose Alberto Fernandez <j_...@yahoo.com>
wrote:

> 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
taskname.

* 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.

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Task proxies (was Re: [GUMP] Build Failure - Fop)

[Peter Donald <pe...@apache.org>]

On Fri, 14 Dec 2001 19:50, Stefan Bodewig wrote:
> On Fri, 14 Dec 2001, Jose Alberto Fernandez <j_...@yahoo.com>
>
> wrote:
> > 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.

anything that refers to another task or datatype is currently broken really 
badly if you expect it to behave the same as if it didn't have an id.

> * Project keeps track of all tasks that have been created for a given
> taskname.
>
> * 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.

And likely to lead to more inconsistencies IMHO.

-- 
Cheers,

Pete

-------------------------------------------------------
"When we remember we are all mad, the mysteries of life 
disappear and life stands explained." -Mark Twain
-------------------------------------------------------

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Task proxies

[Stefan Bodewig <bo...@apache.org>]

On 14 Dec 2001, Stefan Bodewig <bo...@apache.org> wrote:

> What I've been trying ATM:
> 
> * Project keeps track of all tasks that have been created for a
> given taskname.
> 
> * 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.

and I've put it into CVS anyway, just to have a quick fix of the
problem in place.

This one still won't work for user defined tasks that support nested
child elements, but the hassle would be too big IMHO, I'd prefer to
rework our current implementation to use proxies that are converted to
the actual task objects at the latest time possible.

Should this be added to the Ant 1.9 list?

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>