To chime in on this, Oliver never said Open Source. Obviously those of
us that work in that realm believe it to be superior way to develop
software, and I personally at least would love to see the JPA TCK get to
that point as many other TCKs are doing.
However, the point Oliver made was about making it *open*. If I read
Oliver correctly, I took his use of "open" to mean transparent as in
open to within this group which you then elaborated on beautifully.
Just to add to Oliver's list of reasons.. Over the years I have
submitted *many* accepted challenges to the JPA TCK. But the problem
there is that providers who have already certified do not have to
re-certify with the updated TCK, even though they passed flawed tests
(perhaps even passed *because of* flawed tests). Overall it brings into
question the integrity of being "certified" at least to some extent, in
my opinion. It also directly leads to a fragmented JPA community with
major concerns over provider migration. Granted there will always be
provider migration concerns, but I do not think that should happen over
spec mandated (and certified!) features/behavior.
On 01/24/2013 03:23 PM, Werner Keil wrote:
> 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
> <mailto: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 <mailto: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
>
>
>