ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <DDevie...@lgc.com>
Subject RE: <script> and bsf
Date Wed, 11 Dec 2002 15:34:04 GMT
Everything you say is correct Stefan (of course it is ;-), which is why I
think we may consider changing the current 'build a b' from executing
'common,a,common,b' to executing 'common,a,b'. That way, the use case you
describe, and my use case of 'build a b' both work as expected, and the
incompatibility introduced is unlikely to break many people (as Costin, I
don't see the use case for _expecting_ to have common be executed twice).
The few builds that do break would be changed for the better IMHO. Of
course, what I'm advancing here needs to be substantiated by a GUMP run or
two ;-)

And while we're at it, we should also change <ant>/<antcall> as Jose Alberto
suggests to support calling multiple targets. I would OTOH introduce a new
<target> sub-element instead of overloading the meaning of the 'target'
attribute:

<ant antfile="...">
  <target name="buildA" [if/unless] />
  <target name="buildB" [if/unless] />
<ant/>

The fact that <target depends="buildA, buildB"/> uses the comma notation is
not a good reason to introduce it to <ant>/<antcall>, IMHO (and I'd prefer a
<depends target=""/> sub-element there as well.).

--DD

-----Original Message-----
From: Stefan Bodewig [mailto:bodewig@apache.org] 
Sent: Wednesday, December 11, 2002 1:55 AM
To: ant-dev@jakarta.apache.org
Subject: Re: <script> and bsf

On Tue, 10 Dec 2002, Costin Manolache <cmanolache@yahoo.com> 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"/>
</target>

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

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.

Stefan

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