This is a reply to Ken - have you looked into Cactus for doing the deploy,
start, test, stop fuctionality? There is an interesting Ant task that is
part of that project that is designed as a "controller" of three Ant tasks -
start, test, and stop. They already have many common app. servers
integrated nicely into it.
As an aside - if anyone has done this with WebSphere I'd love to hear from
you! I'm beginning to implement Cactus testcases against WebSphere, and
I've yet to find examples of how to do that - I guess I'll have to break new
ground and document it for the Cactus project if/when I figure it out.
Erik
----- Original Message -----
From: "Jose Alberto Fernandez" <[EMAIL PROTECTED]>
To: "Ant Developers List" <[EMAIL PROTECTED]>
Sent: Monday, October 29, 2001 10:02 PM
Subject: Re: Problem with parallel mode
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]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
