There is a release plan for Java EE 7 which tries to mitigate the risk of delaying the whole platform release further. We need to release in the beginning/middle of Feb, 2013 according to the plan. AFAIK, BV guys were only able to (tentatively) commit to the latest possible release date in the end of March which even puts them into a risk of not making it into EE 7 at all. So it's not that BV does not have to keep their final date.
Additionally, we cannot release without RI (Jersey) and in Jersey we obviously need at least a week or two to integrate released BV 1.1 which would move the JAX-RS 2.0 release to a date where we would not make it into Java EE 7 ourselves.
Marek
On Oct 19, 2012, at 7:47 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
> What I do not understand is: Why do we need to final JAX-RS 2.0 earlier than
> the BV guys? Or in other words: If they can move their final date, why can't
> we? What is so different in these two JSRs that we must keep our final date,
> but BV does not?
>
>> -----Original Message-----
>> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
>> Sent: Freitag, 19. Oktober 2012 12:42
>> To: jsr339-experts_at_jax-rs-spec.java.net
>> Subject: [jsr339-experts] Re: [jax-rs-spec users] Bring back
>> BeanValidation
>>
>> Bill,
>>
>> Unless a specification is final, we cannot reference it in the spec. BV
>> 1.1 will not be final before JAX-RS 2.0. So we cannot reference it in
>> the spec. Which means that we would need to talk vaguely about "some"
>> validation, which makes me wonder how useful such spec is. As for the
>> suggestion to specify the integration as part of EE platform spec, I'm
>> not convinced we should define JAX-RS specific algorithms outside of
>> JAX-RS spec. That would make things just less transparent.
>>
>> We do have a plan to address this in a subsequent JAX-RS MR. We tried
>> hard to convince the BV guys to move faster with their spec. We were
>> told not to rush things. I do not think it's fair that they're now
>> trying to rush it on our end by suggesting we adopt some half-baked
>> solution that smells more like a workaround than a reasonable spec work
>> to me.
>>
>> Marek
>>
>> On Oct 18, 2012, at 4:31 PM, Bill Burke <bburke_at_redhat.com> wrote:
>>
>>> I just conversed with the Bean Validation spec lead (Emmanuel) and he
>> is quite upset that JAX-Rs no longer has bean validation integration.
>> While I was a bit happy it was removed initially, because I don't want
>> special classes for it, he convinced me otherwise.
>>>
>>> First and foremost, IMO, it should only be required in a Java EE
>> environment and integration should be specified in the Java EE chapters
>> of the 2.0 spec. Emmanuel defined this particular integration:
>>>
>>> 1. The resource fields and setters are injected 2. fields and setters
>>> are validated and a HTTP 400 is returned on failure to inject @Param
>>> injections. 500 for @Context 3. method parameters are resolved 4.
>>> method parameters are validated and a HTTP 400 is returned on failure
>>> to inject @Param, 500 for @Context 5. method is executed 6. method
>>> return value is validated and a HTTP 500 is returned on failure
>>>
>>> The above does not require any special classes or binary dependencies
>> on the validation spec. This sounds *very* reasonable to me. We
>> require this in a Java EE environment only, IMO.
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>
>