If that can help someone to vent frustrations, you can come and help
Hardy, Gunnar and I write the Bean Validation TCK :D
We can definitively use spare hands as the Feb 20th deadline is
approaching fast ;)
Emmanuel
On Thu 2013-01-24 13:09, Oliver Gierke wrote:
> To be honest, that reads like: we write the tests right before we ship the software. How can the expert group make sure the test we will see eventually are in line with what the spec defines? This essentially leaves us as author of a spec that we will potentially see implementations of that do/can not follow the spec because the TCK we have no influence on didn't catch serious glitches. Where's the value in voting about a spec where the actual rules that govern implementations are not under the control of those who vote?
>
> Beside Steve's issue with implementing the new features of the spec what is the plan for the general work on the TCK going forward? To be honest I think it's close to ridiculous to ask members of the EG to hand in ideas and suggestions for improvements to the TCK which will then be implemented however by whoever somewhere.
>
> Especially in the light of the ambiguities discovered recently I think one of the top priorities going forward has to be that we (the EG) can make sure we'll see the the new features and behavior tested adequately. This not only will help us creating a good/better spec as ambiguities will be found before it is to late but also a much better usability as the lack of defined *and enforced* semantics prevents functionality from being rendered useless as pretty much every persistence provider behaves slightly different as they essentially have no real means to test their implementations.
>
> So I suggest that going forward...
>
> 1. the TCK has to developed alongside the spec by the EG. Newly defined API and functionality has to be backed by test cases on submission of the feature to the spec.
> 2. This requires EG members having access to the TCK during spec development (requires appropriate licensing of the spec)
> 3. If I conclude wishful thinking here I wonder why even the community shouldn't have access to the TCK to maybe help out discovering potential issues.
>
> @Werner: does any of the current JCP versions already define TCK rules like this? The closest JSR I can remember is CDI that always developed an Apache licensed TCK fully in the open IIRC. Or is there any general rules within the JCP/Oracle that should prevent us from going down that route?
>
> Cheers,
> Ollie
>
> --
> Sent while on the run...
>
> Am 24.01.2013 um 21:39 schrieb Linda DeMichiel <linda.demichiel_at_oracle.com>:
>
> > Hi Steve,
> >
> > The team tells me that we are still a number of weeks away on the TCK being ready for this.
> >
> > thanks,
> >
> > -Linda
> >
> >
> > On 1/24/2013 11:49 AM, Steve Ebersole wrote:
> >> A few months ago there was a discussion about early access to the TCK as being a generally good thing and there seemed
> >> to be a general consensus for doing that in any later revisions of the spec. The Cliff Notes (tm) version of the pros
> >> were mainly:
> >> 1) the ability to identify as early as possible problems in the TCK itself
> >> 2) to help providers get started on certifying
> >> 3) allow early feedback from the group as to missing portability coverage
> >>
> >> I was just curious whether we could possibly start getting access to the 2.1 TCK, especially now that the spec is pretty
> >> solidified