ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: <script> and bsf
Date Mon, 09 Dec 2002 17:57:52 GMT
Stefan Bodewig wrote:

> On Fri, 06 Dec 2002, Costin Manolache <cmanolache@yahoo.com> 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).

I committed the fix ( and I reverted part of it because it broke 
typedef tests - but that was because I mixed 2 patches ).

I'll try to clean up the "delayed call for tasks Class.forName()"
and check them in separately, but you can try the 1.119 version
of Project.


>> 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.
 
I think that can be fixed independently of the eval order. 

I'm not sure what is the correct behavior - should "ant A B" behave
like "ant A; ant B" or remove duplicated targets ?
My preferences is the second ( if the user wants C executed 2x, it
can just call ant A; ant B, but there's no way to have it executed once ).



>> ( [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.

I don't. I just remove the reference from the UnknownElement. If the
task is referenced by something else - it'll not be GC. If not - then
we'll free the memory. 

Without that UnknownElement will prevent the GC.



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

Maybe we should revisit the example - even if we preserve the behavior.

Well, the real problem is in the script implementation - the fact
that it "exports" all references and properties. This will not 
work well with the "dynamic properties" and is at least inefficient.

If we can find a way to implement "on-demand" in BSF - then things
might work well. Otherwise - I think exporting only "project"
and deprecating the export of all references would be a good idea.
( deprecate != remove )

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

Well, at the moment Script works - when Script calls getRef
the UnknownElement is instantiated. Very inefficient and ugly,
but it does work.

Costin





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