Hi Xuan,
> -----Original Message-----
> From: Xuan Nguyen [mailto:[EMAIL PROTECTED]
> Sent: samedi 9 juillet 2005 16:33
> To: 'Cactus Developers List'
> Subject: Cactus & Cargo Integration
>
> Hi everyone,
> Thank Vincent for the suggestion in the last post. I have decided to keep
> the Cactus tasks. From the user's side, running cactus test remains with 3
> steps (start container/cactify/config+start+stop). So my plan is rather
> straight forward: Modifying Cactus Task so it:
> 1.call the cargo ant task to set the war/ear in configuration, start the
> container up.
> 2.start the test (junit)
> 3. call the cargo ant task to shutdown the container
>
> The start/config/shutdown will be modified through containerset task.
>
> I suspect about an absolute transparent integration (unless someone can
> convince me this :). In my opinion, we need to pass argument like
> containerid, port, action, etc...into Cargo side and hence a change on
> these
> attributes from Cargo side will have impact on Cactus.
> I would be appreciate for having ideas from your guys on this soon
While one task is good from a usage point of view, I suspect it would force
us to be too much tied to Cargo.
The goal of this Cargo refactoring is really to remove all aspects of
container configuration and manipulation from Cactus. Thus it should be
possible for someone to use his/her own ways of doing this or to use Cargo
which should integrate well.
If you keep on master cactus task, I suspect you'll need to tie Cactus to
Cargo in some manner and this would make us more or less dependent on Cargo,
with the need to redeliver a new version whenever Cargo changes.
Now to answer your question, no there's no need for Cactus to pass any
argument like containerid, port, action to the Cargo tasks. This is done by
the user and that's the beauty of it! :-)
All in all, I think I would prefer about having leaving the user to call the
Cargo tasks to configure/start/stop containers and to have a Cactus task
wrapping the <junit> Ant task to make it easy for users (it would set cactus
properties, set up cactus logging, etc). Actually this could be very similar
to the existing runservertests Ant task (if not the same!).
Are you able to get this independence with a single Ant task? Could you show
us an example of your task in action so that we can see what you mean?
Once again what I mean is a 5 steps:
1/ Create the WAR/EAR using the <war> task for exemple
2/ Cactify the WAR/EAR using the <cactifywar>, <cactifyear> tasks
3/ Configure and start the container using the Cargo task. E.g.
<cargo-resin3x [...] action="start"/>
4/ Use a <junit> wrapper to start the tests
5/ Stop the container using the Cargo tasks E.g. <cargo-resin3x
action="stop"/>
Now, what I mean by the runservertests task is that it's possible to have
something like this (combines steps 3 to 5 from above):
<cactus war|ear="...">
<start>
<cargo-resin3x id="mycontainer" [...] action="start"/>
</start>
<stop>
<cargo-resin3x refid="mycontainer" [...] action="stop"/>
</stop>
</cactus>
That would mean that the user would be free to use whatever Ant tasks he
wants between the <start/> and <stop/> tags.
That said, I don't see much advantage of having that and I think I would
prefer the 5 steps above.
What do other think?
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
