Hi Thomas,

> -----Original Message-----
> From: Th. Schapitz [mailto:[EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to