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 Wed, 11 Dec 2002 07:54:31 GMT
On Tue, 10 Dec 2002, Costin Manolache <> wrote:

> That sounds like a clear bug that needs to be fixed. 

A "bug" that people depend upon - see DD's mail.

>>>> 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.
>> But will the project references table now point to the
>> UnknownElement or to the task?
> It'll store UnknownElement ( i.e. PH will do put() with the UE ).
> But get() method will return the real object (and do a
> maybeConfigure() ).

But this means that it will be a different instance than the task that
has been executed, yes?

Let's get a bit less abstract.  I have a task A and a task B.  A
exposes a public method Object getResult() and would return the result
of its execution with this method.  B has a refid attribute that will
point to an A task, something like

<target ...>
  <a id="my-a"/>
  <b refid="my-b"/>

and inside B's execute method it will do something ugly like

    A a = (A) getProject().getRef(aRefid);
    Object result = a.getResult();

The current CVS HEAD allows this (even though it is ugly and should
not be encouraged and ...).  If getRef() returns something other than
the instance that has been executed, B is in trouble.

I may be willing to break backwards compatibility here as long as we
clearly document it and have good reasons for this move.  The
alternative would be to replace the reference in project's table with
the instance once UnknownElement has been configured.

> BTW, it is quite nice to use a real programming language for
> programming :-) Maybe it would be a good idea to bundle jakarta-bsf
> with ant

As an additional distribution, maybe.  Not in the default

We have been talking about a minimal Ant distribution without XML
parser some months ago (you don't need it with JDK 1.4 or if you
already have one).  And a sumo-distribution (stealing the term from
XEmacs land) would work as well - this could bundle all stuff with
compatible licenses.

In the end it will be a maintenance question.


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

View raw message