On Thu, 18 Apr 2002 07:51, Peter Donald wrote: > > 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.
Should it not? > > <target name="foo" depends="A,B,C"> > </target> > > goes to > > <target name="foo"> > <depends="A"/> > <depends="B"/> > <depends="C"/> > </target> This is an interesting idea. Do we want to go with something like this? (I reckon we should). Would it work something like: <depends name="A"/> - Executes target A in the same execution frame as the calling target. - Only executes target A if it has not already been executed in this execution frame. - Allows the "project->target" syntax for referencing targets in other projects. - Allows property resolution in the name attribute. - Would fail if there is a cycle in the <depends/> calls. - It would not allow properties to be specified. > This supports all of the functionality that people have been asking for. > But it means a "magic" task name (or a magic task). No more magic than, say, <ant> or <antcall>. Let's make it a task, as it should fall out of whatever 'execute-a-target' service we come up with for <ant> and <antcall>. And that means it will be available as a nested task in <if>, and so on. That would also be pretty much the last of the declarative stuff gone too, which wouldn't be a bad thing (now we can have scripty tasks :) -- Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
