Return-Path: <vmassol@pivolis.com>
list-help: <mailto:cactus-user-help@jakarta.apache.org>
list-unsubscribe: <mailto:cactus-user-unsubscribe@jakarta.apache.org>
List-Post: <mailto:cactus-user@jakarta.apache.org>
List-Id: <cactus-user.jakarta.apache.org>
Mailing-List: contact cactus-user-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list cactus-user@jakarta.apache.org
Received: (qmail 28063 invoked from network); 25 Feb 2004 13:03:10 -0000
Received: from unknown (HELO smtp-ft4.fr.colt.net) (213.41.78.203)
  by daedalus.apache.org with SMTP; 25 Feb 2004 13:03:10 -0000
Received: from vma (host.244.109.41.213.rev.coltfrance.com [213.41.109.244])
	by smtp-ft4.fr.colt.net with ESMTP id i1PD39322795
	for <cactus-user@jakarta.apache.org>; Wed, 25 Feb 2004 14:03:10 +0100
From: "Vincent Massol" <vmassol@pivolis.com>
To: "'Cactus Users List'" <cactus-user@jakarta.apache.org>
Subject: RE: Starting/Stopping Resin with Ant
Date: Wed, 25 Feb 2004 14:02:41 +0100
Message-ID: <00e701c3fb9f$a80b23a0$9992fd0a@vma>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <CCDB3BC3-678D-11D8-9DE0-000A95B24066@gmx.de>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N



> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> 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:cmlenz@gmx.de]
> >> 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