ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: [DISC] core extensions
Date Tue, 27 Mar 2001 14:10:20 GMT
At 03:41  27/3/01 +0200, Stefan Bodewig wrote:
>Peter Donald <donaldp@apache.org> wrote:
>
>> At 02:47  27/3/01 +0200, Stefan Bodewig wrote:
>>>>   or enhance antcall to work with current list of executed targets
>>>
>>>This is to avoid running targets twice, right? I've no good idea how
>>>to solve this ATM.
>> 
>I thought this point was about
>
><target name="a" depends="shared" />
><target name="b" depends="shared" />
>
><target name="c">
>  <antcall target="a" />
>  <antcall target="b" />
></target>
>
>where shared would be run twice and a simple depends="a,b" in target c
>would not guarantee that a has been run before b.

<target name="c">
  <antcall target="a;b" />
</target>

<target name="c">
  <antcall target="a" stack="foo"/>
  <antcall target="b" stack="foo"/>
</target>

<target name="c">
  <antcall>
    <target name="a"/>
    <target name="b"/>
  </antcall>
</target>


>
>>>From your description
>
>> I was thinking that we could use frANTics approach. We store a task
>> "stack" [...] . When we climb back into last context (ie antcall
>> finishes) the original is still in pristine condition.
>
>It seems the second antcall doesn't know that share has been run by
>the first one.

true you would need to store the stack (presumably as a variable) and reuse
it.

>wouldn't setTaskContext and getLogger better by part of an abstract
>Task (and why should Task be an interface)? But we are getting into
>details here.

Perhaps but I would rather do a 

interface Task { ... }
class AbstractTask implements Task { ... }

because it serves all people well. Those who want to do crazy stuff can
directly implement task and do whatever. Those who want an easy road extend
AbstractTask (which in reality 99% of tasks would do). However the main
reason for separation between interface/implementation is to force us
developers to design things well. It is much harder to justify adding onto
an interface on a whim than it is to add an extra method to a class ;)

>I thought the request was more something inse build files, along the
>lines of
>
><context id="normal" loglevel="verbose" />
><context id="does.not.work" loglevel="debug" />
>
><target>
>  <sometask context="normal" ... />
>  <someothertask context="does.not.work" ... />
></target>

whoa - in that case I was completely off ;) In what way is the above any
different from enhanced properties + scoping ?

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Mime
View raw message