Brad, You may have an unrealistically high expectation of the workload of committers :-) Many of us committers have constrained bandwidth. However, there's a very broad middle ground between being 'just a user' and being a committer. 'co' a tree, do analysis, post patches to JIRAs. That's (part of) what we'd ask you to do if you wanted to be come a committer, anyway. If JAX-RS is important enough to you to put in some time improving the code or doc of CXF, you can do that on as small of a scale as appeals to you.
--benson On Mon, Nov 10, 2008 at 12:15 PM, Brad O'Hearne <[EMAIL PROTECTED]> wrote: > Sergey, > >> >> Do you suggest us keeping the history of all changes which have been done >> to the configuration ? So that you can look at the page and locate the >> description of your > > That's up to you -- in general it would help to have config doc per version. > But if unable to do that, or if it creates too much documentation overhead > in getting releases out, just make sure that the doc is accurate for the > current release (and I suppose if it is, then there is no overhead for past > versions, just keep the old version of the doc with the old release each > time it is updated for a new version). > >>> - I'm not completely sure about the standards here, so if I'm mistaken, >>> please correct me. I was of the understanding that the >>> jax- rs 1.0 standard specifies the @Produces and @Consumes annotations. >>> CXF does not support these, even in the 2.2 version -- >>> using them results in compile errors. It instead supports @ProducesMime >>> and @ConsumesMime. >> >> I'm wondering how CXF tests using @Produces and @Consumes compile ? Check >> your classpath please, I bet you still have an older jaxrs api hanging >> around... > > I'm absolutely positive that these don't compile on my machine, and I do not > have older jaxrs API's in my classpath -- this compilation was on a new > project which never referenced anything but the newer version. I've never > referenced the older version in this project -- ever -- though I am building > with maven, perhaps there's some funny business in the pom's or something. > >> it does, Honestly - I regret people like yourself who submitted a bunch of >> good patches are not CXF committers yet, as Dan mentioned in his recent >> email, otherwise we'd have more hands and much better docs :-). > > I don't know if this is due to something on your end, or on mine -- I've > certainly never requested to be a committer, and that was probably due to > courtesy -- I didn't want to communicate an unrealistic expectation of > development time available on my end. If you are saying that you want me to > be a committer, then let me know, and what would be expected in doing so, > and perhaps it is something which would be useful. I'm pretty much jax-rs > bound in my projects right now, so I can give good feedback in that portion > of the project. > > Btw, I am also an author, currently writing articles, and one thing which > would be HUGE would be some good articles on using CXF. Myself, I'd actually > like to know more what is going on underneath the hood of CXF. > > Let me know -- back in ancient times I actually did a little work with > Xerces... > > Brad > > > On Nov 10, 2008, at 9:52 AM, Sergey Beryozkin wrote: > >> >> >>> On documentation: >>> >>> - There is literally one line in the RESTFul Services / Jax-rs section >>> which references the existence of a 2.2 version and the >>> extent jax-rs compatibility / support. >> >> There's no 2.2 version yet - it's still SNAPSHOT and it's been updated to >> support 1.0 only a couple of weeks ago. >> >>> >>> - Nowhere does it list specific dependencies for jax-rs. >>> >>> - Even in the How-to build your cxf project with maven section, where it >>> supposedly shows all dependencies possible, there is no >>> listing of the jax-rs dependency in there. >>> >>> - The maven repository you mentioned below is not listed in the pom.xml >>> in the How-to / build / maven mentioned previously. >> >> sure, I'll fix it >> >>> >>> - The beans.xml file in the Configuring jax-rs services for Spring >>> section has a bug in it. There are conficting ID's used by the >>> jaxrs:server and customerService bean. >> >> thanks for pointing it out >> >>> >>> - Nowhere is there mentioned any progress on dependency SNAPSHOTS or >>> current repositories for locating these. >>> >>> - In the past, there have been jax-rs configuration / usage changes in >>> newer versions -- these were not documented. >> >> Do you suggest us keeping the history of all changes which have been done >> to the configuration ? So that you can look at the page and locate the >> description of your currently outdated configuration syntax ? At one point >> of time we had <jaxrs:entityProviders> (introduced thanks to your patch as >> far as I remember). Then I was absolutely certain that when starting to work >> on supporting different types of JAXRS providers I mentioned in the docs >> that soon <jaxrs:entityProviders> would be replaced by <jaxrs:providers> - >> perhaps there's a history of changes there. >> >>> >>> - I'm not completely sure about the standards here, so if I'm mistaken, >>> please correct me. I was of the understanding that the >>> jax- rs 1.0 standard specifies the @Produces and @Consumes annotations. >>> CXF does not support these, even in the 2.2 version -- >>> using them results in compile errors. It instead supports @ProducesMime >>> and @ConsumesMime. >> >> I'm wondering how CXF tests using @Produces and @Consumes compile ? Check >> your classpath please, I bet you still have an older jaxrs api hanging >> around... >> >>> >>> - Not that this cannot be deducted, but in all web services / REST >>> documentation in general, both with CXF and other frameworks >>> I've used, it would be a great help to pair with configuration / >>> annotation documentation a concise explanation of what the >>> final URL your services resides at, depending upon your configuration, >>> i.e.: >>> >>> <webapp-context-root (web.xml)> / <jaxrs:server address (beans.xml >>> address attr)> / <service class path (class file @Path)> / >>> <service method path (method @Path in class file) >> >> ok - makes sense. >> >>> >>> Different configurations vary, of course, but documenting the convention >>> would be helpful. It would also be helpful to have some >>> discussion of the use of the address in the jaxrs:server configuration >>> vs. the service class @Path, and why these would be used >>> as something other than "/" or not. I know that starts entering the >>> domain of REST a bit, but when examples merely show "/", the >>> user is left wondering why it exists at all, or under what circumstances >>> would it be changed, if "/" is the recommended value. >> >> ok >> >>> >>> - A list of changes from one version to another would be helpful. >>> Perhaps this exists somewhere and I don't know where. >> >> agreed >> >>> >>> Hope that helps. >> >> it does, Honestly - I regret people like yourself who submitted a bunch of >> good patches are not CXF committers yet, as Dan mentioned in his recent >> email, otherwise we'd have more hands and much better docs :-). >> >> Thanks for your suggestions abyway - I think I see how the documentation >> needs to be improved - will try to do it asap >> >> Cheers, Sergey >> >>> >>> Brad >>> >>> On Nov 10, 2008, at 5:09 AM, Willem Jiang wrote: >>> >>>> Hi Sergey, >>>> >>>> Can you add this document into the CXF wiki page ? Maybe you can also >>>> add a section of CXF 2.1.x release note :) >>>> >>>> Cheers, >>>> >>>> Willem >>>> Sergey Beryozkin wrote: >>>>> >>>>> Hi >>>>> >>>>> >>>>>> All, >>>>>> >>>>>> If anyone knows the required dependencies (and versions), and any >>>>>> required repositories to build CXF 2.2 with Jax-RS (RESTful services) >>>>>> using Maven, I'd greatly appreciate it. >>>>> >>>>> As far as CXF is concerned, in 2.2-SNAPSHOT, compared to versions >>>>> starting from 2.1.2, the following dependencies have changed : >>>>> >>>>> 1. javax.ws.rs/jsr311-api/0.8 -> javax.ws.rs/jsr311-api/1.0 >>>>> >>>>> it's available from >>>>> >>>>> <repository> >>>>> <id>java.net.2</id> >>>>> <name>Java Net 2 Repository</name> >>>>> <url>http://download.java.net/maven/2</url> >>>>> </repository> >>>>> >>>>> AFAIK, JAXRS team have changed the maven repo starting from 0.8, so if >>>>> you're migrating from CXF with versions earlier than 2.1.2 you might >>>>> see >>>>> artifact download problems. >>>>> >>>>> 2. org.apache.cxf/cxf-rt-databinding-aegis/2.2-SNAPSHOT added - >>>>> compile >>>>> >>>>> >>>>> Some other changes across CXF >>>>> (http://svn.apache.org/repos/asf/cxf/trunk/parent/pom.xml) >>>>> >>>>> - Spring dependencies have changed from 2.0.8 in 2.1.x to 2.5.6 >>>>> - javax.xml.bind/jaxb-api/2.1 >>>>> - com.sun.xml.bind/jaxb-impl/2.1.7 >>>>> >>>>> I'm not aware of any other significant changes which might affect >>>>> JAXRS >>>>> implementation. >>>>> Does it help ? Any specific problems you're still seeing ? >>>>> >>>>>> >>>>>> A kind suggestion: I've been using CXF and Jax-RS stuff for around a >>>>>> year now >>>>> >>>>> thanks :-) ! >>>>> >>>>> . and every time there's been a mild breeze blow which has in >>>>>> >>>>>> any way affected CXF configuration or building in Maven, simple >>>>>> upgrading to the latest version has resulted in a several day plunge >>>>>> down the rabbit hole to figure out how to build / configure again. It >>>>>> would be a great improvement to the release process if at the very >>>>>> least the build / configuration documentation was updated with the >>>>>> latest release. Restated, don't release the code without the build / >>>>>> configuration doc updated. >>>>> >>>>> Your suggestions are welcome and we'll try do do it right for 2.2 once >>>>> it's released. I think Dan is doing a lot of work in this regard but >>>>> capturing version and repository changes would be good indeed. >>>>> In meantime please send a message to a user list whenever you have any >>>>> issues and we'll try our best to help. >>>>> >>>>>> When confronted with this yet again today, >>>>>> despite the fact I have no need or desire to move away from CXF, I >>>>>> spent several hours researching alternatives so that I could avoid >>>>>> having to go through this again. >>>>> >>>>> I'd really hate to see users like yourself who've helped us to push >>>>> CXF >>>>> JAX-RS implementation to its current level go (still not rock-solid >>>>> but >>>>> in a much better shape than it used to be), same way as I hate seeing >>>>> users who've just quickly tried it and decided to look elsewhere. From >>>>> our perspective we know though that users are totally free to choose >>>>> so >>>>> we have really one option - just keep working and make it work well >>>>> and >>>>> I know we'll get there. It's important for users to understand that >>>>> we're committed to seeing CXF as a platform capable of accommodating >>>>> and >>>>> mixing different styles of services. Likewise we'll think hard on how >>>>> to >>>>> make CXF JAXRS 'shine' on its own. There's only one problem - lack of >>>>> resources - for ex I'm not able to allocate 100% of my time to JAXRS >>>>> work so that's why users have to struggle with figuring out themselves >>>>> how to update dependencies/etc. >>>>> >>>>> But as I said, your comments are helpful and we'll take them on board. >>>>> >>>>> Thanks, Sergey >>>>> >>>>>> >>>>>> Thanks -- any help you can give with the question above would be >>>>>> greatly appreciated. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Brad >>>>>> >>>>>> Brad O'Hearne >>>>>> Owner / Developer >>>>>> Big Hill Software >>>>>> ph.480.280.1468 >>>>>> fx.888.600.8806 >>>>>> [EMAIL PROTECTED] >>>>>> http://www.bighillsoftware.com >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -------------------------------------------------------------------------------- >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > >
