On Monday, December 05, 2011 7:21:59 PM David Bosschaert wrote: > Big +1 from me on this (obviously). The fragment approach seems like a > sensible idea to me as a migration strategy.
Another approach COULD be to create a "cxf-core" (not cxf-rt-core) bundle that is a shade/bundle of the 3 (or 4 if we include jaxb). Plus's and minus's both ways. I think LONG term, I'd like a single cxf-core, but I think that it would be better to do that AFTER we kind of go through all 3 jars and figure out what should really be in there and what could be pulled out into separate bundles. For example, all the WSDL stuff in rt-core could likely be pulled into a specific ws-core bundle or something that isn't needed by jaxrs. Some of the interceptors are really ws specific. Etc... But moving all of THAT stuff around would be very problematic. Easily a 3.0 type thing. The stuff I was trying to describe below can likely be done for a 2.6 type things as it's mostly compatible with small, targetted, relatively document- able changes where required. One more area that may be super problematic is the /schemas directory. Haven't had a chance to look at that yet, but a bunch of the jars expose schemas from there and you obviously cannot have a bunch of bundles exposing the same schemas dir like that. That's another huge issue. > 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... Doesn't really work for CXF, at least of the areas I looked at. For the most part, the stuff that needs to move are interfaces that the impls' would need to implement. Thus, without some complex weaving to add the interfaces onto the impls at runtime, it would be a bit more difficult. Dan > > 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 -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
