Generally speaking I agree on this. The api jar has always been actually quite "fat" for an "api" thing.
One question that pops up in mind though is how we're going to deal with api changes in micro releases in the future. My understanding is that so far, any non backward compatible change to the cxf-api would have required at least a minor (e.g. 2.5 -> 2.6) version bump. How will that change with the new cxf-core? Are we going to offer any "stability guarantee" among micro releases here (e.g. 3.0.0 -> 3.0.1)? Cheers Alessio On 07/03/2013 08:39 PM, Daniel Kulp wrote: > > For 3.0, I'd like to combine both cxf-api and cxf-rt-core into a single > jar/bundle. I'd likely just call it cxf-core, but I'm open to other > suggestions (cxf-kernel?). > > We originally tried to have a separate jar for "api" to make javadoc > generation easier, but it pretty much doesn't work. Many of the classes > (like the Service Factories and client factories and JAX-RS client things and > much much more) that you really would need are not part of api and thus don't > appear in the "api" javadoc anyway. Thus, that reason is pointless and not > working. > > API is also WAY WAY more than just "API" now. There are interceptors, data > binding things, all kinds of concrete utility things, etc… API is about 1MB > whereas "core" is about 270K. Kind of shows where the real "core" stuff is. > > As it is, right now, you cannot really have api without rt-core anyway. By > combining them, we can get rid of some of the dynamic import things and such > in OSGi (to find the Bus factory). One less jar to deal with as well. The > jaxrs basic sample would be down to cxf-core, cxf-transports-http, > cxf-rt-frontend-jaxrs, and the related 3rd party deps. > > Thoughts? > -- Alessio Soldano Web Service Lead, JBoss
