ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [myrmidon] CVS move
Date Wed, 17 Apr 2002 21:51:11 GMT
On Tue, 16 Apr 2002 22:46, Adam Murdoch wrote:
> So, this use case covers <ant> and <antcall> where you don't want to
> inherit anything.  I'm not sure we want to execute these in the same
> workspace as the calling task, particularly where we're already executing
> the same project there.  Or do we? 

The consensus seems to be no. Each ant/antcall should be like running ant from 
commandline except you get to pass object parameters aswell.

> What is a workspace, exactly?

a set of projects that reference each other and in which a common thread of 
execution can travel through. ie So basically it is a graph of reachable 
nodes from root project.

Currently it also contains the state of the execution in it aswell.

> Speaking of dependency mechanisms, it would be interesting to allow
> optionally inheriting the target dependency info, so that targets that had
> completed in the parent execution frame would not be executed again.

+1 to enhancing dependency mechanisms so this functionality becomes available, 
-1 to enhancing antcall to do it.

No one has really proposed any specific mechanism to do this in Ant2 but a 
while ago some one proposed something like the following.

Basically you convert the comma serarated list of depends into a set of 
sub-elements in build file. So it would go like this

<target name="foo" depends="A,B,C">

goes to

<target name="foo">

Which is a very nice syntax if you want to intermingle dependency traversal 
and tasks without massive lists of artificial targets. (It also gives us 
syntax to sequence dependencies which people seem to want). So intermingling 
tasks and dependencies could end up with something like

<target name="foo">
  <depends name="A"/>
  <depends name="B"/>

  ...insert rasks here...

  <depends name="C"/>

This supports all of the functionality that people have been asking for. But 
it means a "magic" task name (or a magic task).

> Then there's the whole async thing.  We probably want to start thinking
> about this, 'cause we're going to need it eventually.  If we can come up
> with a model that lets us add this later, without too much grief, then
> that's a good thing.

I have tried it. The only real that will be left (after I integrate the "Java 
Process API" that I am working on) will be writing ProjectListeners that 
respond to the events raised in a graceful manner. You will notice in the 
proposed Event architecture I have a processID which indicates the 
thread/process event is raised from BUT I still have not thought of a nice 
way to display data to user. I g\have tried several approaches and all failed 
:) Any thoughts? 


Peter Donald

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

View raw message