jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: First steps

From: Roberto Chinnici <roberto.chinnici_at_oracle.com>
Date: Mon, 07 Mar 2011 14:59:59 -0800

  I added issues for the following items listed in the JSR:

     a) a low-level client API using the builder pattern => JAX_RS_SPEC-50
     b) a higher-level, REST-friendly client API => JAX_RS_SPEC-51
     c) hypermedia => JAX_RS_SPEC-52
     d) MVC support => JAX_RS_SPEC-53
     e) validation, via integration with Bean Validation API =>
JAX_RS_SPEC-54
     f) JSR-330 and CDI integration => JAX_RS_SPEC-55
     g) asynchronous request processing model => JAX_RS_SPEC-56
     h) "qs" parameter for content negotiation => already present as
JAX_RS_SPEC-1

I skipped this one (too vague):
     i) ease of use, e.g. DRY

Process-wise, we should certainly prioritize the issues. Considering
that we're talking about a few dozen items (only), once the list is
stable I'll go over them and propose new priority assignments. And
before we do that, we need to discuss how to use the five priority
levels the java.net JIRA gives us.

Right now, I'm fine with people bringing up on the mailing list issues
they've encountered (or their users have encountered), clarifying them
and discussing how they relate to existing issues. We'll have to do that
anyway and it's better if the issues filed in JIRA are as clear as possible.

On 3/5/11 2:04 AM, Markus KARG wrote:
> Following the traffic in this mailing list in the last week, I am a bit
> unhappy with the fact that there are currently three sources for our agenda:
> JIRA, JSR and Bill's several emails.
>
> So I want to suggest that first Roberto is adding really *all* items
> (including those of the JSR, not only those from Bill's emails) into JIRA
> and then organizes a way how we will come to a priority list in a democratic
> way.
>
> I do not see any sense in discussing any topics before we have such a
> *single* list, but I do see a lot of things to discuss in rather short time.
> So we should organize our discussions and try to process each item
> separately, sequentially, and I would like to ask Roberto to apply a
> moderating discussion style in the mailing list to allow a professional
> processing of *all* items step by step.
>
> Roberto, what do you think?
>
> Regards
> Markus
>
>> -----Original Message-----
>> From: Roberto Chinnici [mailto:roberto.chinnici_at_oracle.com]
>> Sent: Donnerstag, 3. März 2011 20:30
>> To: jsr339-experts_at_jax-rs-spec.java.net
>> Subject: [jsr339-experts] First steps
>>
>> Welcome to the public JAX-RS 2.0 EG mailing list!
>>
>> A couple of days ago I transferred the open issues from JSR-311 (aka
>> JAX-RS 1.0) to the JIRA for this project [1]. I haven't changed the
>> priorities except in one case, but it seems to me that there are a
>> number of low-priority issues disguised as "major" ones.
>>
>> I'd like to use the issue tracker quite extensively, both to track the
>> items we're working on and to make sure we handle input from the
>> community in a consistent way.
>>
>> When setting up the java.net project, I also transferred the current
>> API
>> sources and the specification sources from JSR-311; they are checked
>> into the git repository for this project (see [2]).
>>
>> Besides the issue tracker, the other major source of work items is the
>> JSR itself [3].
>> Here's a summary:
>> a) a low-level client API using the builder pattern
>> b) a higher-level, REST-friendly client API
>> c) hypermedia
>> d) MVC support
>> e) validation, via integration with Bean Validation API
>> f) JSR-330 and CDI integration
>> g) asynchronous request processing model
>> h) "qs" parameter for content negotiation
>> i) ease of use, e.g. DRY
>>
>> We should start by prioritizing this list as well as the issues already
>> in the tracker.
>>
>> I'd also like to discuss right away any changes we want to make to the
>> goals/non-goals currently listed in the spec (sections 1.2, 1.3).
>>
>> --Roberto
>>
>> [1] http://java.net/jira/browse/JAX_RS_SPEC
>> [2] http://java.net/projects/jax-rs-spec/sources/git/show
>> [3] http://jcp.org/en/jsr/proposalDetails?id=339
>