cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessio Soldano <>
Subject Re: [DISCUSS] api+rt-core -> core
Date Thu, 04 Jul 2013 08:51:45 GMT
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)?


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

View raw message