ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <co...@cortexebusiness.com.au>
Subject Re: Problem with parallel mode
Date Tue, 30 Oct 2001 11:47:07 GMT
Jose Alberto Fernandez wrote:

> From: "Ken Wood" <kwood@i2.com>
> 
>>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:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message