cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Radical structure reorg thoughts for 2.3....
Date Mon, 25 Jan 2010 20:32:17 GMT

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

Mime
View raw message