Parallel, async, I don't care the details of the implementation. I just need to get my job done.
The 'requirement' is to be able to start a server, and run tests against it. This is a build activity, because the server started using the code we just compiled, and the tests are unit tests against the server API. The build is no good if the server can't start, or the unit tests fail... The requirement is also to be able to shutdown cleanly in the event of a test stuck in a loop, and to be able to shutdown cleanly in the event of a build exception. The specifics of how that requirement are moot to me. However, why am I using <parallel> right now? 1. It EXISTS. It's there. All the rest is discussion. And I don't have time to be doing the programming or extensions, or I would already have done it... 2. The Ant 1.4 documentation specifically uses the example of starting a server and running tests against it and stopping the server. If that is NOT what <parallel> is for, then better documentation and examples are in order... -ken P.S. How do I 'check "tests.succesful" to verify if tests passed or not'? That sounds like scripting to me, and Ant doesn't have conditionals or branching... :^) Jose Alberto Fernandez wrote: > > From: "Ken Wood" <[EMAIL PROTECTED]> > > > Another aspect to consider is, how much do we want to focus > > on near term fixes to the Ant 1.x stream of development vs. > > discussing the best way to do it in Ant 2.x? Since Conor > > added the parallel task, I'd be happy to see his proposal, > > and unless there is some tremendous reason NOT to, let Conor > > update parallel for Ant 1.x while we debate Ant 2.x design. > > > > The problem I have here is the BCS (Backward Compatibility Syndrome) whatever > we define today (in a rush) we will have to provide the same functionality in > the future. Like, for example, the issue with <ant> where all the management > of "basedir" is really a mess IMHO. But because that the way it is, now there > is no way to change it. > Even in Ant2, I suspect, we will have to provide ways to mimic this odd > behaviour (even if with different notation) so that people have a way to port > their builds over. > > > In other words, I'd like a solution this week, not 3 months > > of debate (be it civil or not :^) while I continue to kludge > > this by manualing shutdown the server from another console, > > then ending the build from the command line with CTRL-C... > > > > One of the things I notice in the kind of problem you are facing is that you > are trying to use <parallel> to workaround the fact that ANT is unable to > spawn new processes which is what starting a server should mean IMHO. > If you were to have such capability, then one could solve your problem as > follows: > > <target ....> > <spawn ...> <!-- command to start the server --> > <timed maxtime="3600" failoncancel="no" > > <junit ... failonerror="no" > > <property name="tests.succesful" value="true" /> > </timed> > <exec ...> <!-- stop server call --> > <!-- check "tests.succesful" to verify if tests passed or not --> > </target> > > Now, here I am trying to get back to using a single thread of execution by > having a way to really fork a process. > I think such functionality is quite feasible or in the worst case it can be > emulated using daemon Threads. > The other task I propose is <timed> (for lack of a better name). The point of > this task is to alot a certain amount > of time to execute its body, if time is exceeded <timed> is stopped and > depending on the setting the task will fail or not. > > Now, this does not diminish the usefulness of <parallel> nor the need for > more supporting tasks, but it may give us more time to discuss how to do it > right. > > Would something like this cover your needs? > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
