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