Hi Edell, I just had a quick look into Yoko's code base, as far as I can see, Yoko tool model only depends on cxf-api, cxf-common-utilities and cxf-tools-common. cxf-tools-common is a framework mainly for command line parser, tool spec etc. I do not think we have any plan to touch this piece of code as part of tools refactoring. So nothing to worry.
Cheers, Jervis > -----Original Message----- > From: Nolan, Edell [mailto:[EMAIL PROTECTED] > Sent: Friday, December 08, 2006 12:20 AM > To: [email protected] > Subject: RE: Tooling refactoring plan > > > Hi, > > Will you be putting up a design plan for these changes as if > we need to refactor or change things in Yoko then we need to > plan these tasks/changes into our milestones and it would be > good to know in advance. > > Thanks, Edell. > > -----Original Message----- > From: James Mao [mailto:[EMAIL PROTECTED] > Sent: 07 December 2006 12:21 > To: [email protected] > Subject: Re: Tooling refactoring plan > > Hi Edell， > > Yes，i know, the STP project also depends on cxf tools, so > actually the API will not change a lot, by default the API > will keep the same. > But we do allow you to pass in the front end profile or > databinding profile to generate the code other than jaxws and > jaxb And all the refactoring will be stay in tools2, the > tools will be kept until we think it's time to migrate. > > Cheers, > James. > > Hi, > > > > Yoko tools depends very much on the cxf tools and any api > changes will have a big impact so if you intend changing any > - can you send an email to let us know. > > > > Thanks, Edell. > > > > > > -----Original Message----- > > From: Jim Ma [mailto:[EMAIL PROTECTED] > > Sent: 07 December 2006 10:25 > > To: [email protected] > > Subject: RE: Tooling refactoring plan > > > > > > Comments in line. > > > > > >> -----Original Message----- > >> From: James Mao [mailto:[EMAIL PROTECTED] > >> Sent: Thursday, December 07, 2006 5:38 PM > >> To: [email protected] > >> Subject: Tooling refactoring plan > >> > >> > >> > >> The goals of the refactoring are: > >> > >> 1. Reuse the service model > >> 2. Support multiple databinding plugins（jaxb, xmlbeans etc.) 3. > >> Support multiple frontend plugins (jaxws frontend, simple frontend > >> etc.) > >> > > > > Add one goal : > > > > Make our tools more plugable and extensible. Support > pluggable generator to generate deployment descriptor > ,configuration etc . > > Support code modification plugin which can modify the > generated code like JAXB plugin can do. > > > > > > > > >> and we plan to > >> > >> 1. Copy Tools to Tools2, which will depend on RT temporarily. > >> the Tools2 will be a framework, it works as a CLI, > >> and it'll load the service builder plugin, frontend plugins and > >> databinding plugins according to the input. > >> and works as a main controller. > >> > >> > >> 2. After all the test passed, then we start move the > RT/Core to top > >> level Core, after that the dependency of Tools2 looks like > >> API <- Core <- Tools2 <- TestUtils <- RT > >> > >> > >> 3. Move the JaxWs specific processors and generators from > Tools2 to > >> rt/frontend/jaxws > >> Move the Jaxb specific code from the Tools2 to > rt/databiding/jaxb > >> Comments: > >> The benefit of moving is it will keep the tools > framework clean, > >> but it make packaging harder, and the tools in RT, seems weird. > >> > > > > It's weird . I think it should be place to tools . Runtime > only includes the stuff used in runtime . > > > > > >> 4. Migrating to the Tools2, check the testutils works > fine, RT tests > >> pass, System tests pass etc. > >> Remove Tools > >> Rename Tools2 as Tools > >> > >> > >> Comments or Objections? > >> > >> Cheers, > >> James. > >> > >> > >> > >> > >> > >> > >> > >> > > > > > >
