From: "Ken Wood" <[EMAIL PROTECTED]>
> Parallel, async, I don't care the details
> of the implementation. I just need to get
> my job done.
>
Isn't that what we all want?
> The requirement is also to be able to shutdown
> cleanly in the event of a test stuck in a loop, and
> to be able to shutdown cleanly in the event of
> a build exception. The specifics of how that requirement
> are moot to me.
>
In the case of build exceptions (build failures), the standard answer is to use
a BuildListener which shutsdown
the server in case of a failure. Yes it requires programming from you, but it
could be as simple as executing an ANT target that runs the code to shutdown.
> However, why am I using <parallel> right now?
>
> 1. It EXISTS. It's there. All the rest is discussion.
> And I don't have time to be doing the programming
> or extensions, or I would already have done it...
>
Well if you cannot contribute the work, you may need to wait for others to have
the time to contribute the code.
> 2. The Ant 1.4 documentation specifically uses the example
> of starting a server and running tests against it and
> stopping the server. If that is NOT what <parallel> is
> for, then better documentation and examples are in order...
>
I never believed too much on those particular examples, to tell you the truth.
But I did not created that task. ;-)
> How do I 'check "tests.succesful" to verify if tests passed or not'?
> That sounds like scripting to me, and Ant doesn't have conditionals
> or branching... :^)
>
The pattern for doing this is quite well understood given the current ANT
semantics, you just need a conditional target that tests for it:
<target name="tests" depends="run-tests, check-tests" />
<target name="check-tests" unless="tests.successful" >
<fail message="Error during testing" />
</target>
<target name="run-tests">
<!-- more or less the code I proposed before -->
</target>
Jose Alberto
>
> 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.
> >
> > > 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?
> >
>
> --
> 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]>
