cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: Radical structure reorg thoughts for 2.3....
Date Mon, 25 Jan 2010 21:21:47 GMT
Hi Dan,

some comments:

1) If you want to give these modules owwn version I think you should 
move them out of the main cxf tree as it would be confusing if part of 
the tree behaves differently.
I would versioning like it is though. I think it does not hurt to build 
new versions with each release. It also is easier for people searching 
support to say "I use cxf 2.2.5" instead of  "I use cxf 2.2.5, xjc 
2.1.1, ..."

2) same as above

3) I am very positive of having a cxf-core that does not need other cxf 
Ideally the core should need no other dependencies at all. spring-core 
has no dependencies and camel-core has three dependencies. Only cxf-core 
has 23 dependencies. No one can tell me that the core of cxf must be so 
large. I also know that it is not easy to achieve this from the point 
where we are now.

Apart from the effort needed to do backports for older version the 
restructuring will probably also create incompatibilities. Still I think 
it will be worth it.



Am 25.01.2010 21:32, schrieb Daniel Kulp:
> 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.


Christian Schneider

View raw message