Hi
That was the original "goal" of the api module, but it hasn't worked out very well. Part of it is due to the "common-utilities" module which is really "other api's that really should have just been part of API". Another part is the tooling API's are completely separate as well (tools-common) so there are at least 3 "api" modules. The other problem we hit, (it's our own fault, only us to blame) is that we properly put the interfaces and such in api, but when we wrote the impls, we put them in the same package name, but in rt-core or the other modules. This REALLY prevents us from doing any real OSGi stuff other than the big bundle. The proposal wouldn't really fix that though. If api and rt/core are merged, SOME will be fixed, but not all of it. Another issues is that API is really "too large" now, particularly now that we have the JAX-RS stuff. There is a bunch of "ws specific" things in API that really aren't needed for JAX-RS and bring in deps that really are "questionable". Example, why would JAX-RS need wsdl4j? That's another concern we have to at least consider and see if it's something that can be fixed or not. (possibly not, in which case we live with it and move on)
If CXF has WSDL2 implementing at some time in the future then CXF JAXRS might let users see WSDL2 views of the JAXRS services which can be of special interest to users doing both soap and rest given that they will have an option of using a single document describing both soap and rest endpoints. But I don't know at the moment if/when it will happen...Perhaps the most immediate fix for this issue (JAXRS services requiring a wsdl4j dependency) is to ensure a WSDLManager is not loaded for JAXRS-only, I believe it is still the case for 2.3 (I will create a test project).
The other thing to consider is that after 2.3 gets released, the security support may become one of the major themes for CXF JAXRS. Not sure at this moment how much will be done for 3.0/(2.4 ?) but I reckon there's plenty of code in the ws modules which can be reused by the JAXRS code (ex, to do with the message-level security). Thus I'd be looking into creating a common security api as well.
JAXRS services depend internally on the generated EndpointReferenceType. It's a WSA specific artifact/'term' but it's a generated class which can help JAXRS services just fine.
I guess, strategically, there're two approaches toward defining the 'relationship' between the whole of CXF and its JAXRS module. One is to continue viewing CXF JAXRS as one of the CXF frontends. Another, as suggested earlier on, is to move it into a separate subproject. The former approach puts some pressure on the cxf-api, there're few bits there which are not needed by cxf jaxrs. The latter would keep a clear separation between CXF the SOAP and CXF JAXRS but would still keep the pressure on the cxf-api. I'm in favor of the 1st approach. IMHO the1st approach has many advantages, one of them is that is that it is not SOAP vs REST after all, the other to do with the speed of development, etc...
Sergey
