Good point. Let's use next Monday (3/14, end of day Pacific Time) as
the deadline for new issues.
On 3/8/11 9:18 AM, Markus KARG wrote:
> 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
>