cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ma, Erqiang \(Jim\)" <jim...@iona.com>
Subject FW: tooling and service model
Date Wed, 20 Sep 2006 07:51:44 GMT
Comments inline .

> -----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 :-)

I'd like to hear your plan in detail. What's the more and What's the new tools2 will be ?


Will you use the XFire way to build new tools2 ? If so , I want to say the following : 

[1] XFire use the string equals way to process the command flags user prompted . Now tools
 use the more flexible and powerful  way to parse the command line. It's easy to extend .
 

[2] XFire use the SUN's JAXB RI code model to generate types code , SEI and Service code and
other stuff  . It's also not an ideal way.  I think we need only use sun's jaxb ri  to generate
databinding code .

[3] XFire jaxws tool do not resolve the generate class name collision . It also need to be
considered .

But I still -1 to create new tools.

>
> > 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.
>

Can you explain why current tools do not work fine again? Last time we only discuss what need
to be refactored  in tools module and we do not discuss tools do not work fine .
 
> 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.
>

Could you point out why it's a pretty drstic change ?  I think it's easy to refactor. 
 
> >>
> >> I'm in the midst of refactoring this now. I probably won't get the 
> >> code in until tomorrow though. I'll try to explain once I get it 
> >> finished :-)
> >>
> > Cool, just make sure all the system tests and demos working properly.
> 
> I don't usually test demos when I do commits. That would really slow 
> down the development process. If there is something in the demos that 
> isn't covered in the tests, you should add it.

+1

System tests is ok . If system tests is passed , I think most of demos can work .


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message