cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bacon, Stephanos" <sba...@iona.com>
Subject Re: Tooling Proposal [was Re: tooling and service model]
Date Fri, 22 Sep 2006 09:20:37 GMT
So I'm guessing that by bringing iona's rationale for not refactoring the tools, you probably
broke some kind of apache taboo.

I get the impression that in Apache the normal kind of "why waste time rewriting something
that works" kind of argument doeant hold water because there is no concept of schedule.  If
the result is cleaner code, then there is a good arument for doing it.

I suspect you'll get flamed :-)

-steph

-----Original Message-----
From: Lin, Bozhong
To: cxf-dev@incubator.apache.org <cxf-dev@incubator.apache.org>
Sent: Fri Sep 22 02:22:39 2006
Subject: RE: Tooling Proposal [was Re: tooling and service model]

I also agree that it makes a lot of sense to leverage current Celtix tooling implementation
and to do any refactoring only for meeting new requirements. These tools are fundamental to
application users and IONA has spent tremendous effort in the past year to maintain and tune
the Celtix tools, making sure that it passes all kinds of complex WSDL and Schema, including
many issues reported by Celtix users. [1].

Cheers,
Bo

[1] http://forge.objectweb.org/tracker/index.php?group_id=192&atid=350241  

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: Thursday, September 21, 2006 10:05 PM
> To: cxf-dev@incubator.apache.org
> Subject: Tooling Proposal [was Re: tooling and service model]
> 
> 
> >
> >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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message