From: Werner Keil <werner.keil_at_gmail.com>
Date: Thu, 24 Jan 2013 22:23:51 +0100

Oli/all,

In an ideal world, that's how TDD works[?] And based on the session Patrick
and others from the PMO held a while ago on TCKs, a TCK must not be
tailored towards one implementation or the RI only, so if a Spec Lead
company is large enough like in this case, ideally the part that writes the
TCK should not necessarily be the ones who write the Spec or RI, though in
some situations of course they may interact.

Regarding the license, I believe the Spec page
http://jcp.org/en/jsr/detail?id=338 section 2.18 makes it very clear, that
neither RI nor TCK for 338 are licensed under Apache or any other Open
Source license. Nor are JSON or WebSockets, just to mention 2 other parts
of the Java EE 7 Umbrella. In those cases the Spec isn't even in a public
repository, while RI is, though certain licenses may also apply for
commercial purposes beyond R&D, other Open Source Projects that go as
Non-Profits or those "Qualified Individuals".

JCP.next is not about "Make everything Open Source", it is about a
transparent way of designing and developing the JSRs with as little "deals
behind closed doors" as possible, or none[?]

HTH,
Werner

On Thu, Jan 24, 2013 at 10:09 PM, Oliver Gierke <ogierke_at_vmware.com> 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
>