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?
Jose Alberto
> -ken
>
> P.S. not meaning to start an offshoot thread, but I've
> always been a proponent of keeping Ant close to its 'procedural'
> roots and not become excessively 'scripty'. But I guess
> there is a fine line between where procedural ends and scripting
> begins. I see my '<catch>' idea as being procedural (declare
> what to do in the case of a build exception), but I agree the
> 'kill' part looks scripty, unless you consider it a declaration
> of how to end other threads under certain conditions. Maybe
> <stop refid="xxx"/> would be more politically correct than 'kill' :^)
>
> Jose Alberto Fernandez wrote:
> >
> > I don't know... This looks preaty much like scripting. ;-)
> >
> > I think we need to put some more thought on how do we want <parallel> and
> > <sequential> tasks to interact with each other and with the build process
> > itself.
> >
> > For example, what should a parallel branch of the build do when another
> > branch receives a BuildException?
> > In a plain sequential build the only accion is to stop the build. We all
> > know all the discussions about whether having an "onerror" target or using
> > buildlisteners to detect failures. How does that discussion deals with
> > parallelized builds?
> >
> > I think we are seeing another aspect of the same issue here, but mascaraded
> > by the fact that we have things
> > going on in parallel. And then we have the regular issues of how to manage
> > threads in general <join>, <kill>
> > <wait>, <timelimit>, etc. Do we really need all that? Can we get most of
> > the same with less tasks?
> >
> > I think we need to start a *nice* thread of discussion about this issues
> > and design it properly, as oppose to
> > just try to solve the problem for particular examples. Don't get me wrong,
> > examples are useful to test the usefulness of a proposal, but we need to
> > understand how all the pieces work toguether and any other unforseen
> > concequenses.
> >
> > Thoughts?
> >
> > Jose Alberto
> >
> > ----- Original Message -----
> > From: "Ken Wood" <[EMAIL PROTECTED]>
> > To: "Ant Developers List" <[EMAIL PROTECTED]>
> > Cc: "Ant Users List" <[email protected]>
> > Sent: Monday, October 29, 2001 2:54 PM
> > Subject: Re: Problem with parallel mode
> >
> > > I was wrestling with a similar issue last week.
> > >
> > > I start weblogic in one 'parallel' branch, and run
> > > test cases in another branch. When the test cases
> > > end, they shutdown the server. But, sometimes the
> > > test cases get hung, and the build never ends.
> > >
> > > I had thought of doing a "sleep hours=1" in a third branch,
> > > followed by the code to stop the weblogic server. Now, in
> > > the case where the branch that runs the tests against
> > > the servers gets hung up for some reason, this time out
> > > branch would shut down the server. But, it wouldn't stop
> > > the hung test branch. And, if the test branch succeeded,
> > > the 'sleep' branch would keep the build running for whatever
> > > remains of the 1 hour timeout. So, I didn't pursue it...
> > >
> > > What I wanted was to have an 'kill' that I could use.
> > > If the 'sleep' branch got to the end of the sleep, it would
> > > then run the code to cleanly shutdown the server and to
> > > 'kill' the hung test code. And, if the test code branch
> > > finished first, it would shutdown the server cleanly (as
> > > it already does) and then 'kill' the timeout branch that
> > > is still sleeping. An example:
> > >
> > > <parallel>
> > >
> > > <sequential id="server">
> > > code to start the server
> > > </sequential>
> > >
> > > <sequential id="tests">
> > > code to run tests
> > > code to stop server
> > > <kill refid="sleep"/>
> > > </sequential>
> > >
> > > <sequential id="sleep">
> > > <sleep hours="1"/>
> > > code to stop server
> > > <kill refid="tests"/>
> > > </sequential>
> > >
> > > </parallel>
> > >
> > > Now, to deal with the original issue raised, we need to
> > > be able to catch an exception that happens when a failure
> > > occurs. How about this:
> > >
> > > <sequential id="tests">
> > > <catch>
> > > code to stop server
> > > <kill refid="sleep"/>
> > > </catch>
> > > code to run tests
> > > code to stop server
> > > <kill refid="sleep"/>
> > > </sequential>
> > >
> > >
> > > The code declared within <catch> would only be executed if
> > > a build failure exception was thrown during the running
> > > of the tests.
> > >
> > > Conor MacNeill wrote:
> > > >
> > > > I'm copying this over to Ant-dev. Please follow up there
> > > >
> > > > Quintus, Guenter wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > i am running ant 1.4 using the parallel tag.
> > > > > Weblogic is started in one branch, in the second some test cases are
> > > > > runned and there is also a stop method for the weblogic task.
> > > > > But if there is an error at testing ant will still stop the execution
> > > > > for branch 2 which is ok but weblogic is still running at branch 1.
> > > > > Is there a way to tell ant to stop every branch in case of an error?
> > > > >
> > > >
> > > > There are a few issues here. Firstly, this would need to be configurable
> > > > I guess ("one dead - all dead" versus "dead thread does not affect other
> > > > threads"). The other issue is that Ant doesn't actually know how to
> > > > "stop" the Weblogic process.
> > > >
> > > > We could explore allowing some tasks, particularly tasks based on
> > > > embedded <exec>'s to be terminated. In the case of <parallel>, it could
> > > > use Thread.interrupt() to break the waitFor() call in Execute. In that
> > > > case the InterruptedException catch should forcibly terminate the
> > > > process. The logic in <parallel> would need to be updated a bit too.
> > > >
> > > > Thoughts anyone? I'll try this out this week sometime.
> > > >
> > > > Conor
> > > >
> > > > --
> > > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> > > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> > >
> > > --
> > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> > >
> >
> > --
> > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
