ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: <script> and bsf
Date Fri, 06 Dec 2002 21:31:10 GMT
Stefan Bodewig wrote:

> On Thu, 05 Dec 2002, Costin Manolache <> wrote:
>> Can you give me more information, I'm a bit confused...
> The JavaScript test uses tasks by reference, before the corresponding
> targets have been run.  This works right now as ProjectHelper creates
> instances of the tasks while parsing.

> What you should look for is whether the test is still going to pass
> with the delayed task instantiation of your embed proposal.  If it
> does, we can savely assume that the change doesn't affect older
> builds.  Or at least I'd trust it more 8-)

I got it to pass - with some change in the code for UnknownElement2
and one change in Script ( that can also be done on a global level
in Project ).

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, or by explicitely checking for UE in Script ( this will 
work for ant1.5 - since the Script task can be replaced, but the references 
hashtable can't ). 

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.
( [embed] is also removing the reference to the task after each
invocation - to help GC ).

So the test can pass with delayed loading of the task. 

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

The first part ( special Hashtable for refs ) is very usefull and matches
very well the dynamic properties ( i.e. it can be a nice extension point,
to allow dynamic references ). It is also simplifies the PH, and 
is IMO a good thing to do.

The second part is a different story. I think it is very ugly and 
likely to create more problems in future - and it may be worth 
introducing a backward incompatibility. This affects all code that
is manipulating Tasks in the build tree - and will be very important
in future for "meta" tasks like <import>.
Having a clean model with a tree of UE and deterministic behavior
( you allways know what is in the tree ) is far better than the 
current "it may be a task or an UE - but it'll magically turn itself
into a task if some events happen".

Regardless of the decision on this issue - the replacement is easy
to implement ( or at least enough to pass the Script test ).

Another issue is the implementation of Script - it does get all the
refs and declares them in the BSF. This won't play well with the
dynamic properties, requires internal access to the project - and
I think it's not very good. 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 trying to get around BSF and see if it is possible
to have BSF call some dynamic method to get the beans it needs (instead
of pushing them in before ).



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

View raw message