Hi Sergei, I am also a bit concerned about autocomplete feature actively used in IDEs (mentioned by Dan). Keeping unsupported element in schema can be a bit confusing because of that. Therefore if handling the client in the old namespace via the transformation feature will be too complicated in option (1), I would prefer option (2) with keeping dependency client -> frontend.
Regards, Andrei. > -----Original Message----- > From: Sergey Beryozkin [mailto:sberyoz...@gmail.com] > Sent: Freitag, 6. Juni 2014 11:57 > To: CXF Dev > Subject: How to get a public jaxrs.xsd at org.apache.cxf support multiple CXF > versions > > Hi > > In CXF 3.0.0 we've had a "client" element used to be defined in jaxrs.xsd > shipped with the rt/frontend/jaxrs module moved out (alongside with the code > supporting Client API) to a new jaxrs-client.xsd (with a new target namespace > http://cxf.apache.org/jaxrs-client) now shipped with the rt/rs/client module. > > This is documented in the migration guide. > > Note that I've updated a target namespace for a 'client' element not for some > design reasons but only due to the fact that I came to the conclusion it was > not > possible to have a shared/single target namespace for schemas shipped in > multiple modules. > > So, after 3.0.0 has been released I've pushed a new jaxrs.xsd schema without > the 'client' element to org.apache.cxf. And we've started getting reports of > CXF > 2.x clients using jaxrs:client getting the validation issues. > > So I wonder what would should the best strategy be for supporting multiple CXF > versions validating against a public jaxrs schema be, without having to > introduce the numbers or dates into target schema namespace (just for the > sake of simplicity, given that the schemas are in themselves are very stable > now, with only very attributes or optional elements possibly added in the > future). > > I can think of 4 options: > > 1. The current workaround has been to restore the old 'client' element only in > the public jaxrs.xsd at org.apache.cxf/schemas just to keep CXF 2.x clients > using > jaxrs:client getting the validation working. > If it works and will have no side-effects over a some period of time then may > be > we can settle with this solution, even though it's effectively a hack. > > 2. Revert the migration of 'client' into a new target namespace > "jaxrs-client", > have "client" restored in jaxrs.xsd, and either 'include' jaxrs.xsd or use it > directly in rt/rs/client. The downside: we will never be able to break a link > between RS client and RS frontend modules, which is on the map, at the > moment only the RS frontend has benefited from getting the client code moved > out of it, while the client code is still depending on all of the frontend > RS; may it > is not a big deal really > > 3. In CXF 3.0.1: update a shipped jaxrs.xsd to have a new target namespace, > "http://cxf.apache.org/jaxrs3x";, restore the old jaxrs.xsd at org.apache.cxf > and > redirect "/jaxrs3x" requests to a new jaxrs3x.xsd file. > This is probably the best solution as far as the best practice is concerned. > > 4. Add jaxrs2x.xsd file to org.apache.cxf and advise CXF 2.x clients working > with > jaxrs:client update schemaLocation elements accordingly. > This will work but kind of not cool, breaking the validation for the existing > working clients is not good, even though it is a tiny change. > > Any comments please ? > Right now I'd like to see if 1. works and open to doing 3. in CXF 3.0.1 > > Thanks, Sergey > > >
