ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: Problem with parallel mode
Date Tue, 30 Oct 2001 20:34:51 GMT
From: "Conor MacNeill" <>

> Jose Alberto Fernandez wrote:
> > 
> > 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.

Yes, we need to be careful not falling on that one either. I just want us to understand the
consequences of the proposals that get put out. For example, there has been all this discussion
about whether to allow build files to detect their own errors and act on them (i.e., the failure
target discussion). Now, for reasons completely different there is this idea of <catch>.
Can I use such construct to catch and act on failures even if not using <parallel> or
<sequential>? If yes, what do the people that argued against having access to the failure
feel about it? If not, why not.

I would like to discuss those sort of unintended (or intended) consecuences before we put
some task out there that we cannot take back because of BCS.

> 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.

Which means that ANT2 has to provide a way to express the every behaviour we are trying to
change in ANT2. In reality there is no way to get rid of any bad thing we have put 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?)

Not to <parallel> but to <sequential>. As I conceived the task, we are giving
a particular amount of time for the body to
execute sequentially. I call it differently to avoid confusion. If the task exceeds the alloted
time, the task gets cancelled and fails (unless failoncancel="false").

> <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.

True on both comments, This is why I say <parallel> has its own value and I am not trying
to replace it. I just think that it is not the right tool for the problem Ken has.

Can you point to one of such patches? I am trying to see it it can be implemented as an attribute
called "detach="yes/no".

> > 
> > 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?

Ken was talking about having a solution in a week (not that is a binding schedule or anything).
If I know this list correctly it may take more than that to get the right mix of tasks to
control <parallel>. :-)

Jose Alberto

> Conor
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

Do You Yahoo!?
Get your free address at

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message