I kind of did a little audit this morning to try and figure out how hard it
will be to split the big bundle into little bundles to allow for smaller OSGi
footprints and such by just loading the desired functionality into OSGi
instead of the entire big bundle (and all it's deps).
At this point, we have 25 packages that are split across multiple jars. 16
of the 25 are split between common-utilities, api, and rt-core. At this
point, I'd likely just say make those 3 fragments of each other. In the
future, then figure out how to split that "big" bundle up a bit better. Some
of the 16 are "easy" (like cxf/phase) but not really worth spending time on if
all of them cannot be resolved.
Of the remaining 9, 5 are easy to resolve, 2 are "medium", and 2 are hard and
would have a big impact.
Here is my analysis:
"Big 3" packages:
org/apache/cxf/binding cxf-api cxf-rt-core
org/apache/cxf/buslifecycle cxf-api cxf-rt-core
org/apache/cxf/clustering cxf-api cxf-rt-core
org/apache/cxf/configuration cxf-api cxf-common-utilities cxf-rt-core
org/apache/cxf/configuration/spring cxf-common-utilities cxf-rt-core
org/apache/cxf/endpoint cxf-api cxf-rt-core
org/apache/cxf/feature cxf-api cxf-rt-core
org/apache/cxf/headers cxf-api cxf-rt-core
org/apache/cxf/interceptor cxf-api cxf-rt-core
org/apache/cxf/io cxf-api cxf-rt-core
org/apache/cxf/phase cxf-api cxf-rt-core
org/apache/cxf/service cxf-api cxf-rt-core
org/apache/cxf/service/invoker cxf-api cxf-rt-core
org/apache/cxf/transport cxf-api cxf-rt-core
org/apache/cxf/workqueue cxf-api cxf-rt-core
org/apache/cxf/wsdl cxf-api cxf-rt-core
Not easy:
org/apache/cxf/jaxb cxf-common-utilities cxf-rt-databinding-jaxb
Classes from both are used all over the place. Big user impact.
We COULD consider JAXB databinding a "core" thing and fragment it
in since JAXB is pretty much required for any usage of CXF.
org/apache/cxf/service/factory cxf-rt-core cxf-rt-frontend-simple
Couple classes in rt-core used by JAX-RS and thus not really pushable into
frontend-simple without pulling more deps for JAX-RS. Changing package
name in either place would affect users. (changing package for
classes in rt-core would affect a LOT less users though)
Medium:
org/apache/cxf/ws/policy cxf-api cxf-rt-ws-policy
Move impls and interceptors to private package. May impact users if
referencing the impls/interceptors directly.
Push abstract and basic stuff up to cxf-api
Couple other issues to resolve (like WSPolicyFeature requires Spring)
org/apache/cxf/ws/addressing cxf-api cxf-rt-ws-addr
Moving all the classes from api to ws-addr can be done. Users would need
to depend on cxf-rt-ws-addr in addition to cxf-api if using the classes.
The main one is the AddressingProperties interface. Some internal CXF
classes will need to be updated and fixed, but nothing major. The only
"hard" one would be AbstractMultiplexDestination's call into the
AddressingProperties, but that's all of 2 lines of code and could likely be
handled better by have ws-add save the "TO" EPR on the message/exchange
directly.
Easy:
org/apache/cxf/frontend cxf-rt-core cxf-rt-frontend-simple
Move from rt-core to sub-module (not used elsewhere anyway):
org/apache/cxf/management cxf-common-utilities cxf-rt-management
Change package for generated type. No impact to users.
org/apache/cxf/transport/http cxf-rt-core cxf-rt-transports-http
Impl in "core" moved to private package, utility class moved to common
Possible impact to users as the utility class would move.
org/apache/cxf/tools/common cxf-api cxf-tools-common
Move to tools-common and update refs or replace with constants
org/apache/cxf/tools/validator cxf-api cxf-tools-validator
Move to tools-validator and adjust dependencies and set optional imports
Anyway, what are people's thoughts on the above? Is it worth pursing more
closely for 2.6? Other than the JAXB one above that still needs a good
solution, the impact isn't very large and could easily be documented in the
migration guides.
Dan
