cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <...@envoisolutions.com>
Subject Tooling Proposal [was Re: tooling and service model]
Date Thu, 21 Sep 2006 14:05:08 GMT
Liu, Jervis wrote:

>  
>
>>-----Original Message-----
>>From: Dan Diephouse [mailto:dan@envoisolutions.com]
>>Sent: Wednesday, September 20, 2006 1:00 PM
>>To: cxf-dev@incubator.apache.org
>>Subject: Re: tooling and service model
>>
>>
>>James Mao wrote:
>>
>>    
>>
>>>Hi Dan,
>>>
>>>      
>>>
>>>>I would like to start a set of parallel tool modules. Say create a 
>>>>directory called tools2 and get things working there. Once we're 
>>>>ready we can work on switching the whole build to the new tools.
>>>>        
>>>>
>>>The tools2 will include all the functions in cxf tools?
>>>      
>>>
>>And more :-)
>>
>>    
>>
>>>and how long will it take? 
>>>      
>>>
>>Depends on how fast we can type :-)
>>
>>    
>>
>>>and when we say switching you mean include porting all the 
>>>      
>>>
>>unit tests 
>>    
>>
>>>and system tests to the tools2? and also make demos work properly.
>>>So, your goal is to replace cxf tools with tools2?
>>>      
>>>
>>Yes, yes, yes.
>>
>>    
>>
>>>or let user choose which one they want to use?
>>>      
>>>
>>No.
>>
>>    
>>
>>>But i really have a question why we need to create another 
>>>      
>>>
>>tools when 
>>    
>>
>>>the current tools works perfectly fine?
>>>      
>>>
>>Because they don't work fine. I believe we had this 
>>discussion before... 
>>Please see the previous threads on tooling.
>>
>>    
>>
>I do remember we had some discussions before regarding CXF tooling, but as far as I can
recall, I do not think we are anywhere close to reach a conclusion that CXF tools need to
be totally rewritten. 
>
>
>  
>
>>If you want to try to refactor the current tools in place, I 
>>suppose we 
>>could try that. But its a pretty drastic change, so I don't 
>>really see a 
>>step-wise process to do it. I think it would be better to 
>>just write a 
>>second set of tools, then when they're ready switch 
>>everythign over and 
>>delete the old tools.
>>
>>    
>>
>
>
>Refactoring current tooling or writing a brand-new one are both ok as the ultimate goal
is to have a better tooling. But it would appear to be too early to tore down everything we
already have and invent the wheel from scratch before we can answer questions below:
>
>1. Identify exact problems in our current tooling, and what problems can be resolved through
refactoring and what problems can not be resolved elegantly as it is due to core architecture.

>
>I just went through our mailing list and found following tooling relevant discussions,
do let me know if I am missing anything.
>
>a. CXF tools need to support WSDL2.0
>b. CXF tools need to support SOAP1.2
>c. We need to reuse Service Model in tools, this will bring us WSDL2.0 and SOPA1.2. There
were some discussions around how to do this. One proposed approach is moving Service Model
as a top level module, one is using Service Model as a plug-in. To me, they are implementation
details and we shall be able to figure out which way is more appropriate when we are doing
this work. 
>d. Support multiple databindings and multiple front-end profiles generations. With the
code merged from XFire code base, the current CXF tools should have this capability in place
already. 
>  
>
e. Reduce code duplication

>Based on this observation, I feel a refactoring is a more practical approach, doing (a)(b)(c)
should be a one week work. At the same time, I have to say some interfaces in our current
tools are a bit confusing, for example, the ToolsContainer interface. This makes new developers
hard to following the tooling architecture in order to do their contributions. I suggest we
do another refactoring on this after getting service Model done. But overall, I do not see
any critical problems that can not resolved through refactorings based on the information
I have right now. 
>
>2. If we are to write a new tool from scratch, what are the feature list we have in mind,
and how long do we expect to reach this feature list. 
>
This is not what I'm proposing at all. I too feel this would be silly.


Here is what I'm proposing:

   1. Rewrite the generation part of the tooling to use the Service
      model instead of the wsdl. This would involve using the
      ServiceFactory to build a ServiceModel and then writing out class
      files from there.
   2. Have tools depend on the core for the service model and put each
      frontend's generation plugins in the frontend themselves. Moving
      the service model to a separate module or common doesn't make any
      sense whatsoever because we still need to depend on the
      ServiceFactorys which are in the frontend, so there will be a
      dependency on core.
   3. Add SOAP 1.2 support to the SoapBindingFactory
   4. Add WSDL 2 support to the core (WSDL2ServiceBuilder, etc)
   5. Do this refactoring in a tools2 module. While I don't anticipate
      that this is a lot of work, this will help us get around the
      circular dependency issues and allow us to temporarily break a few
      things.
   6. Extra credit: use the CodeModel from Sun instead of our own.
      Having our own creates unnecessary work and it is also too tied to
      JAX-WS to be useful outside of it. If you look at JAXB, a whole
      host of plugins have arose partly because they use this code model
      that anyone can plug into. As its really not a lot of work to use
      it instead of our, I think we should.

I think we can do this relatively easily and its not as big a deal as 
people are making it out to be. The Celtix tooling is good, and I don't 
want to rewrite it all, I merely want to evolve it.

Cheers,
- Dan

-- 
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


Mime
View raw message