ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject Re: ProjectComponentHelper and adapters
Date Thu, 14 Mar 2002 07:04:14 GMT
From: <costinm@covalent.net>

> On Wed, 13 Mar 2002, Jose Alberto Fernandez wrote:
> 
> > That would mean that once a task in a target is resolved to a particular definition,
> > that definition stays in place. Since in regular ANT each target is evaluated only
once,
> 
> I see nothing wrong with keeping the invalidation logic ( or maybe I don't
> understand all the issues here ). Removing it may not be backward 
> compatible, so I'm at least -0. ( the invalidate() is not public, but
> the behavior should be preserved )
> 

The question is whether it would be needed at all. If we do not resolve to a particular
task class until just before executing the task for the first time, then the main reason
for invalidation (i.e., a definition was resolved before <taskdef> got a chance to execute)
will not be an issue anymore. By the time the element gets resolved, your <typedef>

would have been executed.

The case this do not cover is when we execute the same target several times (not via <ant>
or <antcall>) and somehow on each reexecution we change the definition of what the task
mean.
E.g.: <xxx> is first resolve to "o.a.t.a.t.Copy" the next time to "o.a.t.a.t.Move" ,
the next time
to "o.a.t.a.t.Delete", etc. Now, such mutating behaviour seems to me has no justification.
One thing is late binding, but this is self modifying programs.

I do not see any use case where people need support for such a behaviour, I actually think

it is a bug in the current code to allow such thing. Once a task instance is executed, it
should
stay committed to its definition.

Jose Alberto 



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message