You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-dev@jakarta.apache.org by "Th. Schapitz" <sh...@ePost.de> on 2004/12/07 11:46:48 UTC

Remote Cactus, solved

Hi Vincent,

as you might have noted, I uploaded the patch to one of the issues.
As this is my very first patch to an OpenSource project, don't be shy 
about critics.... ;-)

Seeing all this references to Cargo,  and comparing this to my note 
regarding deployment in an earlier mail, what are your plans with the 
'Cargo refactoring'?

To me, this looks like it would be totally sufficient, if all containers 
supported the nested <startup> and <shutdown> tags, or something similar.

 From the point of view of usability, it might be best, if we deprecate 
<startup> and <shutdown> and reimplement these tags as subtags 
<beforeTest> <afterTest> in AbstractContainer, the rationale beeing, 
that the user remains free to choose, what ever he wants  to do 
(deploying, bouncing the container) with what ever means he likes to 
utilize.

This would also avoid to introduce the cargo classes as dependency into 
Cactus.

Opinions?

Thomas


---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org


RE: Remote Cactus, solved

Posted by Vincent Massol <vm...@pivolis.com>.
Hi Thomas,

> -----Original Message-----
> From: Th. Schapitz [mailto:shalmaneser@ePost.de]
> Sent: mardi 7 décembre 2004 11:47
> To: Cactus Developers List
> Subject: Remote Cactus, solved
> 
> Hi Vincent,
> 
> as you might have noted, I uploaded the patch to one of the issues.
> As this is my very first patch to an OpenSource project, don't be shy
> about critics.... ;-)

Yes, I've seen you had provided a patch. Very cool! Just give me a bit of
time to review it (life is hectic ATM).

> 
> Seeing all this references to Cargo,  and comparing this to my note
> regarding deployment in an earlier mail, what are your plans with the
> 'Cargo refactoring'?

I've started working on the Cargo refactoring on a CACTUS_17_CARGO_BRANCH
branch. I've just committed what I have done so far to show what I have in
mind. The file to look at is: 

jakarta-cactus/samples/servlet/src/scripts/share/build.xml

Basically I wanted first to try using Cargo directly. So a Cactus user would
use <cactifywar> to cactify a WAR and then using directly the <cargo-*>
tasks to start the container, then he would use the <junit> task to start
the Cactus tests and again the <cargo-*> tasks to stop  the container.

Obviously the following step could be to wrap all this using some thin Ant
task wrapper that would chain all those tasks. What I would like is to keep
the ability for the user to directly be able to benefit from the container
support we keep adding to cargo without having to wait for a new version of
the cactus wrapper. Simply using a newer version of Cargo should be enough.

> 
> To me, this looks like it would be totally sufficient, if all containers
> supported the nested <startup> and <shutdown> tags, or something similar.

Could you be more explicit? (maybe I need to look at your patch first?).

> 
>  From the point of view of usability, it might be best, if we deprecate
> <startup> and <shutdown> and reimplement these tags as subtags
> <beforeTest> <afterTest> in AbstractContainer, the rationale beeing,
> that the user remains free to choose, what ever he wants  to do
> (deploying, bouncing the container) with what ever means he likes to
> utilize.
> 
> This would also avoid to introduce the cargo classes as dependency into
> Cactus.
> 
> Opinions?

Could you please give more context as I'm a bit lost to understand what
you're suggesting. Are you talking about refactoring the existing <cactus>
task? Are you talking about the current <runservertests> task? Are you
talking about the <generic> nested element of the <cactus> task?

Thanks
-Vincent


---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org