Re: Proposal to refactor CXF dependencies. WAS: RE: Tooling Proposal [was Re: tooling and service model]

[Dan Diephouse <da...@envoisolutions.com>]

Hi Jervis,
Sorry I didn't get feedback earlier - but this sounds good. I'm with Dan 
K on his suggestion about Step 1/rt renaming though.

I will definitely try to chip in as I'm the instigator here. I have 
things to finish up for M1 before I can start working on this, but I 
think I could help by doing
1. Getting XMLBeans databinding working
2. Doing the WSDL 2.0 work

Can you explain what you were referring to about the Transport work? Are 
there any other areas you want me to tackle?

- Dan

Liu, Jervis wrote:

>Hi, can I presume there is no objection to this proposal? ;-) Obviously this is a big story, to move things forward, I would like to suggest we start from tools refactoring and anything needed for tools refactoring, such as jax-ws frontend and  serviceModel etc. To minimize the risk of breaking mainline and to allow others working on non-tools refactoring work in parallel(such as moving databinding, transport etc from core to rt), we will take an incremental step by step approach, at the end of each step, we need to make sure all changes are committed to mainline and everything should build and run ok.
>
>Below are action items we need to take related to tools refactoring, jax-ws and serviceModel.
>
>Step 1: 
>1. Rename rt to core. 
>2. Create a new directory and module called "rt" (or plugins). Move jax-ws from core to rt.  
>
>Cost: 1-2days  
>
>Step 2: 
>1. Move tools module and testutils module after core, before rt. So the dependency path will look like:
>Common <- API <- Core <- Tools <- testuitls <- rt(only contains jax-ws at this moment) <- Systests    
>2. Move any jax-ws related code from tools module to jax-ws module. Tools load jax-ws capabilities as plugins.
>3. non-jaxws module should not contain any jax-ws related code. Currently we use jax-ws generated artifacts in a lot of places for testing. This needs to be fixed.
>
>Cost: about 1 week. I expect we will have to spend a lot of time on removing jax-ws generated artifacts from non-jaxws modules.
>
>In order to not break mainline for a week, I suggest we create a tools2 to hold the work of step2. Once everything is working all tests passed using tools2, we can replace tools with tools2.
>
>Step 3:
>1. Refactor tools to use ServiceModel. ServiceModel lives in core, it provides a generic model to represent information from wsdl and classes. jax-ws specific info is loaded into serviceModel by JaxwsServiceModelBuilder through plugins. JaxwsServiceModelBuilder lives in jax-ws module.
>2. Add soap1.2, wsdl20 supports into tools by leveraging ServiceModel.
>
>Cost: about 1 week
>
>
>Overall we expect we can finish tasks listed above in about 2 to 3 weeks. Both James and myself are interested in working on this. As guys in Beijing are taking 7 days off from 1st Oct to 7th Oct to celebrate National holidays, we can probably kick off from the second week Oct. As I personally take 2 weeks off from 1st Oct, I will join James from the third week Oct. If things going well, we can finish this by the end of October. Note, we do not plan this work for the coming cxf release.
>
>Of course, we also need more volunteers to own non-tooling part refactorings, such as transport, databindings etc.
>
>Does this sound good to everyone?
>
>Thanks,
>Jervis
>
>
>
>
>  
>
>>-----Original Message-----
>>From: Liu, Jervis 
>>Sent: Thursday, September 28, 2006 2:37 PM
>>To: cxf-dev@incubator.apache.org
>>Subject: Proposal to refactor CXF dependencies. WAS: RE: Tooling
>>Proposal [was Re: tooling and service model]
>>
>>
>>Hi, we have come out with some new ideas (hopefully better 
>>ideas ;-)) on how to resolve dependency problems we have been 
>>trying to resolve in this email thread. Below is a summary 
>>from IRC chat and email discussions:
>>
>>1. Promote core to top level. Remove these "extra 
>>functionalities" from core, the core remain as small as 
>>possible and only provide basic and absolute necessary 
>>functionalities. Anything considered as "extra" are moved to 
>>rt module (or rename it to plugins). The core acquires those 
>>"extra functionalities" through loader plugin. The new 
>>dependency path will be: Common <- API <- Core <- Tools <- 
>>RT(frontend, databindings etc) <- Systests
>>
>>2. Candidates that will be moved from core to rt include: 
>>a). Frontend: jax-ws, js
>>b). Databindings: jaxb
>>c). Transports: HTTP, JMS
>>d). Protocol bindings: SOAP, XML 
>>d). anything else?
>>
>>3. ServiceModel lives in core, though this serviceModel only 
>>provides basic model info. Extra things like jax-ws info is 
>>loaded into serviceModel during runtime through plugin loaders.
>>
>>4. "tools" module provides a basic "tojava" tool and a basic 
>>"towsdl" tool that just takes a ServiceModel and does not do 
>>specific things.   The other things (frontends, etc..) would 
>>provide a plugin that would add a "-jaxws" or "-pojo"  or 
>>"-wsdl11" or "-wsdl20" command line switches (or similar) to 
>>those tools to enable processing those things.   
>>
>>5. tools module is after core. The good thing is, first we 
>>wont have any problems to make tools depend on serviceModel 
>>anymore, as the serviceModel is in the core. Secondly and 
>>most importantly, tools can use a "Bus.init()" to have a bus 
>>load all the available plugins etc. This way we reuse the 
>>plugin configurations from bus, it is the Bus's 
>>responbilities to search classpath etc to load plugins.
>>
>>How does this sound to everyone? We need to figure out an 
>>exact list on what remains in core and what get moved to rt.
>>
>>Cheers,
>>Jervis
>>    
>>
-- 
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com