Hello,

After CDI and Maven, here's my turn with the JAX-RS tooling (as part of the Web Services component).

1/ Bring support for @Provider annotated classes. The JAX-RS specification provides this nice way of decoupling the actual Resources Methods (ie: java methods that are invoked when a URL is requested) from the way to (un/)marshall the content on the wire. 

There are 2 kinds of JAX-RS Provider: 
- classes that implement the MessageBodyReader and/or MessageBodyWriter interfaces are responsible for unmarshalling the request entity (request body) received from the client and marshalling the response entity sent back to the client. JAX-RS implementation must provide a set of 'Providers' to work with XML/JSON format (the most popular), but nothing exist by default when it comes to other formats (v-card, etc.). 
- classes that implement the ExceptionMapper: these classes are used to convert the exception thrown by some layer into an appropriate response body to the client (including a proper response code). This avoids returning an ugly stacktrace that the client would fail to process anyway

As part of the tooling, some validation could detect that a JAX-RS ResourceMethod consumes or provides a mime-type for which there is no default MessageBodyReader/MessageBodyWriter or that the java method throws a given type of exception for which there is not ExceptionMapper. A quick-fix could provider a wizard to create the appropriate @Provider. 

The custom providers could also be displayed in the Project Explorer, aside of the currently displayed Endpoints.

Field injection is also part of the specification but I think it is less used, so that could postponed until JBT 4.1 / JBDS 6.1

2/ More validation and quick-fixes. For example, the JAX-RS Resource Methods won't be called if no JAX-RS Activator has been configured. It can be either a subclass of javax.ws.rs.core.Application or some servlet mapping in the web deployment descriptor. Or something proprietary (CXF or RESTEasy deployed with Spring). 
As part of the tooling, we could detect the lack of JAX-RS Activator and provide the user with a wizard to configure one (java class or web.xml). For vendor-specific ones, the validation could be disabled for now.  

3/ Improving content assist on @PathParam annotated method parameters : the content assist is only available when the cursor is within the comma of the annotation value. The content assist producer should work in more cases. Also, one nice little feature I'd like to see is the ability to rename both : the method parameter and the @Path template value / @PathParam value at the same time. Eg:

@GET
@Path("{id}")
public Response getCustomer(@PathParam("id") Integer id, @Context UriInfo uriInfo) {
ResponseBuilder responseBuilder = Response.ok().entity(null);
return responseBuilder.build();
}
From my experience, "id" is often both used to define the URL Template parameter (as part of @Path and matching in @PathParam), but also to name the associated method parameter. Renaming the method parameter could also rename the URL Template parameter.  

4/ Fixing existing bugs.

As JAX-RS 2.0 is on its way, I need to look at it and see if there are areas in which the tooling could help the users get started more easily (client side code, interceptors, etc.)

If you have other suggestions to add or comments to make, please do ;-)

Thanks
Best regards,
/Xavier