Re: Starting/Stopping Resin with Ant

[Matt Raible]

Comments at bottom...

On Feb 25, 2004, at 6:02 AM, Vincent Massol wrote:



-----Original Message-----
From: Christopher Lenz [mailto:[EMAIL PROTECTED]
Sent: 25 February 2004 13:26
To: Cactus Users List
Subject: Re: Starting/Stopping Resin with Ant
Am 25.02.2004 um 11:07 schrieb Vincent Massol:
-----Original Message-----
From: Christopher Lenz [mailto:[EMAIL PROTECTED]
Sent: 25 February 2004 10:56
To: Cactus Users List
Subject: Re: Starting/Stopping Resin with Ant
In that case I'd suggest extending <runservertests> so that it
would
accept a nested <containerset>, similar to <cactus>. This approach
would be much cleaner than providing separate <startcontainer> and
<stopcontainer> tasks IMHO.
Except that :
1/ we don't need/want a containerset, just a single container
(unless
you wish to start several containers in parallel).
<containerset> is simply the data type, basically the main interface
through which you access the functionality provider by the container
package from an Ant build file. There is currently no such thing as a
container outside of a containerset, although we could probably
provide
support for that for Ant 1.6 build files (while still working in 1.5).

Second, multiple containers would not be run parallel, but
sequentially. The nested "test" task would be repeated for every
container.
Ok I see. My initial idea was to provide 2 simple start/stop tasks and
leave it for the user to do whatever he wishes before after it is
started. But you're right, we also provide the hook to do something in
between and support the stop after the start.
I'm fine with your solution or modifying runservertests to support
automatic start/stop.

2/ it's not about run server tests. It's simply about starting a
container. Thus the name is misleading. I'd much prefer a new task.
The name was always misleading, as you can use <runservertests> for
everything you like. Still, it is mostly used for tests, because the
container is shut down after whatever you wanted to do is finished,
and
that functionality is not very useful in non-test related contexts.
I'm
not against changing the name, however.
ok


That can get messy though, because the task basically gets two
different modes: the first is using the classic start/stop hooks,
the
second mode would be based on container sets. Note that the first
mode
could be dropped, because a generic container inside a container
set
supports the same semantics, but simply dropping the start/stop
hooks
would break backward compatibility. I recall working on this, but
gave
up because I didn't need it myself.

This would be simpler if we'd simply make this a new task
(<runcontainer> or <incontainer>?).
that's what I'm proposing with
startcontainer/stopcontainer/runcontainer
I think.
<runcontainer> is okay. As I said before, I'm not in favor of separate
start/stop tasks because that is soooo procedural (yuck ;-) ). We want
a more declarative syntax, like:
run tomcat4x so I can:
   run all my integration unit tests
   run all my functional tests based on canoo webtest or whatever
So how about:

   <runcontainer>
     <containerset><tomcat4x .../></containerset>
     <sequential>
       <!-- do whatever you like here, the container is running -->
     </sequential>
   </runcontainer>
In Ant 1.6 we drop the <containerset>:

   <runcontainer>
     <tomcat4x .../>
     <sequential>
       <!-- do whatever you like here, the container is running -->
     </sequential>
   </runcontainer>
Basically, we can also drop the <sequential> block, but I think it is
nice in keeping the actual tasks together in a block.
Does that sound okay?
Yep. +1 from me. runservertests will be deprecated and replaced with
runcontainer.
Matt, what do you think?

Thanks
-Vincent
I don't think I know enough about what I'm doing to comment on this.  
Once I've dug in and understand how everything works, then I'll report 
back with my findings and a proposed solution.  We can then discuss how 
my solution should be improved to fit the greater need.

Matt

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]