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

[jsr339-experts] Re: First steps

From: Markus KARG <markus_at_headcrashing.eu>
Date: Tue, 8 Mar 2011 18:18:21 +0100

Sounds good, but shouldn't we have some kind of deadline for new items, at
least a soft one? I mean, I'm a friend of fast progress, you know. ;-)

> -----Original Message-----
> From: Roberto Chinnici [mailto:roberto.chinnici_at_oracle.com]
> Sent: Dienstag, 8. März 2011 00:00
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: First steps
>
> 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
> >