cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Radical structure reorg thoughts for 2.3....
Date Mon, 25 Jan 2010 23:19:43 GMT
Hi Dan,

how about having a real small API. Currently the cxf api consists of 41 
and has a about 10k lines of code (without comments).
I don´t understand why things like transport.http or 
messsage.MessageImpl and message.ExchangeImpl have to be inside API. The 
same for wsdl.JAXBExtensionHelper, the whole ws.adressing and ws.policy 
stuff.  I would even doubt that the wsdl package is necessary. Of course 
this is more something for cxf 3 ;-)

An even more radical idea would be to define an API around the core of 
cxf, camel and servicemix and make this the basis of all three products. 
Things like Exchange and Message would belong there. I don´t know 
exactly how the scope could be set but I have the feeling that the core 
ideas are more or less the same in the three products. A common API 
would perhaps even make it possible to share transports,  frontends and 
databindings with camel and servicemix. Basically I don´t think it is 
necessary to have separate http and jms transports in cxf, camel and 
servicemix. In fact they do almost the same. This could allow CXF to 
focus more on the ws specifications.

Greetings

Christian

Am 25.01.2010 22:53, schrieb Daniel Kulp:
> That was the original "goal" of the api module, but it hasn't worked out very
> well.   Part of it is due to the "common-utilities" module which is really
> "other api's that really should have just been part of API".   Another part is
> the tooling API's are completely separate as well (tools-common) so there are
> at least 3 "api"  modules.
>
> The other problem we hit, (it's our own fault, only us to blame) is that we
> properly put the interfaces and such in api, but when we wrote the impls, we
> put them in the same package name, but in rt-core or the other modules.  This
> REALLY prevents us from doing any real OSGi stuff other than the big bundle.
>
> The proposal wouldn't really fix that though.  If api and rt/core are merged,
> SOME will be fixed, but not all of it.
>
> Another issues is that API is really "too large" now, particularly now that we
> have the JAX-RS stuff.   There is a bunch of "ws specific" things in API that
> really aren't needed for JAX-RS and bring in deps that really are
> "questionable".     Example, why would JAX-RS need wsdl4j?   That's another
> concern we have to at least consider and see if it's something that can be
> fixed or not.   (possibly not, in which case we live with it and move on)
>
>    
>> I'm not very familiar with the CXF internals, so I don't know if the
>> api/rt-core separation in CXF reflects that distinction between public
>> API and internal classes, but if it does, I would suggest not to make
>> the same mistake as Axis2.
>>      
> :-)
>
> Dan
>
>
>
>
>    
>> Andreas
>>
>> On Mon, Jan 25, 2010 at 21:32, Daniel Kulp<dkulp@apache.org>  wrote:
>>      
>>> I'd like everyone's thoughts on some ideas I have to do some minor
>>> restructuring for 2.3.  I'm just throwing this out there as some ideas.
>>> We don't need to do any of this if people disagree or would find it
>>> annoying or similar.   I just want peoples thoughts....
>>>
>>> 1) We have a bunch of xjc plugins in common/xjc that really never change.
>>> There really isn't a reason to have a 2.3 version and a 2.2.6 version and
>>> such.   They are pretty much completely shareable.    Thus, I'm thinking
>>> of creating an "xjc-plugins" sub-project to house these.  We could just
>>> release them once and re-use them until new plugins are needed/created.
>>> common/xsd (our xjc wrapper maven plugin) would probably go there as
>>> well.
>>>
>>> 2) Likewise, buildtools and maven-plugins/xml2fastinfoset-*  are really
>>> RARELY changed.   I'd like to have a "build-tools" subproject for these
>>> type things. This is partially to support (1) above so the checkstyle
>>> rules and such are more shareable, but it also would remove a few modules
>>> from the build.
>>>
>>> 3) Most radical idea:   I'd like to merge what's left in common/*  after
>>> (1) into api.   Possibly also merge parts or all of rt/core into API.
>>> If we do that, possibly just rename api to "cxf-kernel" or make it
>>> cxf-core or similar. common-utilities, api, and core are really not
>>> useable without each other at all.   You cannot do much without all three
>>> so merging them together seems to make some sense.    POSSIBLY
>>> tools-common as well.   I  need to look into that one a bit more.    We
>>> COULD potentially move some stuff OUT of api/rt-core that is more ws
>>> specific (like the wsdl manager stuff) and into a ws-core or something
>>> that wouldn't be needed for JAX-RS.   Not sure how much of an impact that
>>> would have.
>>>
>>> Doing 3 MAY allow better OSGi support as we really would have a "kernel"
>>> with pretty much EVERYTHING else being plugins into our kernel.
>>>
>>> There will be a slight build speedup as less modules are built and less
>>> calls to checkstyle and such, but nothing major as a majority is in the
>>> systests. Now that we've gone with Surefire 2.5, I MAY experiment with
>>> the parallel setting on a couple of the module, probably cannot on the
>>> systests though.
>>>
>>> Now, the MAIN drawback from all this would be merging fixes to 2.2.x is
>>> going to be much harder in those modules.   I think that would mostly
>>> affect me though.
>>>
>>> Anyway, I'd like to know what people think about all this.
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://www.dankulp.com/blog
>>>        
>>      
>    


-- 

Christian Schneider
---
http://www.liquid-reality.de


Mime
View raw message