Well, I'm glad it turned out well.
Jeanfrancois Arcand wrote: > > Ken Wood wrote: > > >Perhaps I missed something, but Ant already does 'almost' this same thing > >by using the <parallel> capability of of Ant: > > > > <parallel> > > <sequential> > > <exec A ....../> > > <exec B ...../> > > </sequential> > > <exec C .... /> > > </parallel> > > > >In this construct, A and C are started at the same time, while B waits for A > >to finish before it starts. > >If C needed to wait before starting (say it depends on A being up and > >running) you could do: > > > > <parallel> > > <sequential> > > <exec A ....../> > > <exec B ...../> > > </sequential> > > <sequential> > > <sleep X /> > > <exec C .... /> > > </sequential> > > </parallel> > > > >Or, another example: > > > > <parallel> > > <javac A .... /> > > <javac B..... /> > > <javac C.... /> > > </parallel> > > > >The above starts three compilations running in parallel. > > > >So, what I'd like to know is, what is the benefit of 'spawn' over use of > >'parallel', > >besides the fact that a spawned process can remain running after Ant > >finishes?? > >Remember, while Ant is put to many uses, it's original and main purpose is to > >run a build.... So, can we say a build is 'done' when Ant has finished, but > >has left > >spawned processes running? What happens, for example, if one has 'spawned' > >various java compilations, and then Ant finishes. Is the build done? How can > >we tell? So, I think we cannot tell what is going on.... Sure, spawn may be > >great if you are using > >Ant for something else, but not, I think, for builds. However, I'm > >interested in being > >shown otherwise... :^) > > > You are right. I should RTFM. I just tried and it works fine (better > that my solution). Rrrrr at least I've learned how ant works. > > Thanks, > > -- Jeanfrancois > > > > >Dominique Devienne wrote: > > > > > > > >>Thanks for all the hard work Jean-Francois. > >> > >>1) Could you open a new BugZilla enhancement, and attach you patch there? > >>This would allow to discuss you changes there, easily referenceable. > >> > >>2) Why did you have to modify Task.java? It doesn't seem warranted, and > >>probably will not fly well with the committers. > >> > >>3) Any chance you might be able to write unit tests specific to the 'spawn' > >>mode of <exec>? > >> > >>Also, what happens of the spawned process stdin/stdout/stderr? Do you force > >>redirecting to a file? If I spawn a process from Ant, Ant finishes, and I > >>close the console, will the program stop and/or hang and/or its output will > >>simply be lost??? > >> > >>Thanks, --DD > >> > >>-----Original Message----- > >>From: Jeanfrancois Arcand [mailto:[EMAIL PROTECTED] > >>Sent: Wednesday, January 22, 2003 1:29 PM > >>To: [EMAIL PROTECTED] > >>Subject: [Proposal] Running task asynchrously (+ patche) > >> > >>HI, > >> > >>attached is a tentative patch that allow a Task object to run > >>asychronously. I have tested the patch on Solaris and win2k and > >>everything works fine (without breaking backward compatibility). > >> > >>To use the functionality, you just have to add to a task the spawn > >>attribute, e.g.: > >> > >><exec dir="c:/src/jakarta-tomcat-5/build/bin/" executable="sh" spawn="true"> > >> > >>Since some task needs a couple of seconds to start/stop, I also added a > >>spawnWaitUntil attribute where you can set the time required before > >>moving to the next Task. > >> > >>I did no wrote a <spawn> task because I think the functionality should > >>be available to every Task. For now I did not add the functionality to > >>Java, Javac, Jar. > >> > >>Let me know what you think. At least I have something use when <gump>ing > >>tomcat :-) > >> > >>Thanks, > >> > >>-- Jeanfrancois > >> > >>-- > >>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > >>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > >> > >> > > > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
