ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: <script> and bsf
Date Mon, 09 Dec 2002 14:11:38 GMT
On Fri, 06 Dec 2002, Costin Manolache <> wrote:

> The major issue is the use of the ref - which points to an
> UnknownElement.  We already discussed about this - it can be solved
> using a special Hashtable,

I know (and knew) that.  Sorry for being so terse in pointing it out.
I knew the way embed worked would break the test and I knew you could
fix it (that way).

> The second issue is replacing the UE with the real Task in the
> Target.  In [embed] we don't do that - under the assumption that the
> tree can be executed several times, and it is cleaner to keep the
> UE/RuntimeConfigurable and create the tasks on each invocation.

IIRC the has been an issue with

ant A B

where tasks in a target C that both A and B depend upon will be run
twice but take advantage of the fact that they will be the same
instances.  I can't remember the details.  As long as Gump builds as
good as before and our own test cases pass, we may be save.

> ( [embed] is also removing the reference to the task after each
> invocation - to help GC ).

This will cause some extra problems.  This is hear-say and I have no
references to back this, but people on the user list mentioned that
they use references to store state.  So they may rely on references to
old tasks (those that have been run) to point to the "real" tasks.  If
you remove the references, you must not remove them from the Project
reference table.

> The big question is if we do want it to pass. 

Like I said.  This test is nothing but the prove that what <script>s
documentation says since Ant 1.2 still works.  I'd have a hard time to
justify breaking our own examples.

> The first part ( special Hashtable for refs ) is very usefull


> It may be much better to use delayed eval - and that can be done
> with a syntax change ( i.e. access the refs indirectly, using
> project.getRef() ). That would certainly break many Script
> useages.

I'm afraid this is true.


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

View raw message