It's fine with me Xuan. Thanks -Vincent
> -----Original Message----- > From: Xuan Nguyen [mailto:[EMAIL PROTECTED] > Sent: dimanche 10 juillet 2005 04:02 > To: 'Cactus Developers List' > Subject: RE: Cactus & Cargo Integration > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
