Big +1 from me on this (obviously). The fragment approach seems like a sensible idea to me as a migration strategy.
WRT to changing packages, if you are really worried about backward compatibility but would like to refactor the split packages out you *could* consider renaming the package and creating a compatibility bundle or fragment that contains the 'old' split packages and delegates to the new ones. The users can slowly migrate. Non-migrated users would need the compat bundle. Migrated ones will not need it... It's not always practical, but it's an option to consider... Cheers, David On 5 December 2011 17:40, Daniel Kulp <[email protected]> wrote: > > 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 >
