Hi everyone, To summarize, we have three options here 1. Hide Cargo completely from users (my original approach) 2. Let users to use Cargo attributes (start/config/stop)without introducing any new attributes(Vincent first approach) 3. Let users to use Cargo with new nested attributes which use Cargo (Vincent second approach)
For me 2 and 3 are similar, 3 is more clean. However, I also prefer 2 as I don't see much use in 3. As the final purpose is for a transparent integration, I vote for 2 though it gives the users some extra work and their knowledge on cargo. Any one has other options for this and what do you think ? I would like to have a final agreement on this matter soon while understanding that your guys may be busy for other stuff ;) Cheers Xuan -----Original Message----- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Sunday, 10 July 2005 2:14 AM To: 'Cactus Developers List' Subject: RE: Cactus & Cargo Integration 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
