From: "Conor MacNeill" <[EMAIL PROTECTED]> > 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: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
