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"> </target> goes to <target name="foo"> <depends="A"/> <depends="B"/> <depends="C"/> </target> 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"/> </target> 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? -- Cheers, Peter Donald -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
