The main use-case I would have for <spawn> (or <exec spawn="true">) is to start up my app. Ant is quite convenient and expressive when it comes to specify path/classpath/env. vars, arguments, etc... in a portable manner.
My start and test targets both require a lot of common-setup, and since I need it in Ant for test, I use a similar setup to start the app too. I'd also like to popup IE with the generated Javadoc or HTML report when a task concludes, with Ant exiting. That sort of little things which are not build stuff per-se, but quite useful and convenient. But that's my take on it ;-) --DD PS: Plus I've always been kind of suspicious of <parallel>, perhaps wrongly. -----Original Message----- From: Ken Wood [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 22, 2003 4:42 PM To: Ant Developers List Subject: Re: [Proposal] Running task asynchrously (+ patche) 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... :^) 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]>
