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.
Well the flipside of BCS is DPS (Development Paralysis Syndrome). We don't develop anything because it might conflict with the way Ant2 may do it, although we can't seem to agree on what or how Ant2 may do. The release delay between 1.3 and 1.4 is somewhat attributable to this paralysis and is what Ken is getting at, I think.
In fact Ant2 is a BCBP (Backward compatability Break Point). We accept that it will not be backward compatible. What we have committed to do is, IMHO where practical, to provide an Ant 1.x -> Ant 2.0 conversion tool and that we won't change things just for the fun of it.
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>
Your concept of <timed> could be applied to parallel just as easily, couldn't it
<parallel timelimit="3600" fail="any"> (not sure what failoncancel is?)
<spawn> is a good idea (or better as an attribute of exec/forkedjava for which there have been some patches) but it is a little bit of a separate issue. There may be occasions where you want to run a task, perhaps not a server, within the Ant VM in parallel to other tasks.
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.
Not sure why <timed> would give us more time. What is the timelimit?
Conor
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
