I have raised this issue with our TCK team and asked them to follow up.
-Linda
On 8/31/2012 6:07 AM, Steve Ebersole wrote:
> While "more openly accessible" is certainly desirable, as a provider what would be far more desirable is early access.
> For example, I already have through the latest spec drafts implemented in Hibernate; it would be amazing to be able to
> test that work against the TCK as it stands thus far. That serves 2 purposes:
> 1) Helps me validate my work (making providers better)
> 2) Helps identify TCK problems earlier (making providers more consistent).
>
>
> On Fri 31 Aug 2012 04:00:11 AM CDT, Oliver Gierke wrote:
>> As quite a few people of the expert group agree about that the TCK should be more openly accessible and we didn't see
>> an official reply yet, let me summarize my questions up:
>>
>> 1. What's preventing us from changing the TCK license to e.g. Apache 2.0? Other JavaEE specifications (e.g. CDI [0])
>> have been on that track for years.
>> 2. Can the current license still be changed in the course of the 2.1 specification or do we have to wait for 2.2?
>> 3. If there's no way to open up the TCK for 2.1, what is the process to track discovered TCK glitches? The JSR JIRA?
>>
>> Cheers,
>> Ollie
>>
>> Am 27.07.2012 um 16:24 schrieb Matthew Adams <matthew_at_matthewadams.me>:
>>
>>> +1
>>>
>>> On Wed, Jul 25, 2012 at 2:32 PM, Steve Ebersole <steve.ebersole_at_redhat.com> wrote:
>>> +10000
>>>
>>> Early access to the TCK (in progress) is by far the best way to (1) catch holes in the TCK and (2) keep it improving.
>>>
>>>
>>> On Fri 20 Jul 2012 08:10:50 AM CDT, Scott Marlow wrote:
>>> On 07/19/2012 01:03 PM, Oliver Gierke wrote:
>>> I think this is crucial as I have seen tickets in implementors bug
>>> trackers with comments that bugs won't be fixed if the TCK doesn't
>>> actually bark. This way, it's actually not the spec driving the
>>> features/bugs of the implementation but a TCK not even members of
>>> the expert group get access to. This effectively creates a shadow
>>> spec which is a sub-optimal thing to see I think.
>>>
>>> If you could help in pointing these out, that would be very useful.
>>> Our team certainly wants to know about such
>>> problems.
>>>
>>> There's been a couple of comment threads in implementors bug trackers
>>> which I've stumbled above. The quickest one I could find was one
>>> inside the Hibernate bugtracker [0]. This is by no means finger
>>> pointing at Steve, as ironically he and all the other leads of the
>>> implementations actually can't do much more than follow the TCK. If
>>> it leaves holes and the spec is not as tight as it should be, they
>>> essentially have no choice.
>>>
>>> One practical example of these is that
>>> EntityManager.createNamedQuery(…) didn't throw an exception in case
>>> of an invalid query name provided for *two major versions* (2.0 and
>>> 2.1). This actually relates to the discussion we have in the separate
>>> thread which I'll respond to in a bit. Yet another example is again
>>> Hibernate [2] (sorry Steve, I owe you a beer :), which didn't
>>> implement Metamodel.managedType(…) correctly by throwing an exception
>>> for embeddables and mapped superclasses. Once again, I think the TCK
>>> could have caught that, making our lives (the implementor as well as
>>> the clients) a bit easier.
>>>
>>> Essentially this boils down to two categories: one is slight
>>> ambiguities in the spec which need to be discussed and improved (and
>>> which we probably won't ever get rid off entirely). The other - even
>>> worse - are things that actually *are* defined in detail by the spec
>>> but not enforced and then potentially show up to anger users and
>>> implementors. They are not worse because they are more crucial. They
>>> are worse because it would have been easy to catch them early on if
>>> the TCK actually underwent the same open discussion as the spec does.
>>>
>>> In my experience, one of the issues is timing. When the EE TCK
>>> becomes available, the priority for the vendors implementing EE, is to
>>> pass the TCK. In theory, when vendors initially get the early EE TCK
>>> snapshots, that would be a good time to report to Oracle, that a
>>> certain SPEC requirement is not covered but that is probably not going
>>> to happen as much (since vendors are focused on passing the TCK
>>> instead of improving it). I'm all for a more open/transparent TCK
>>> process but I'd like to read how we actually want to improve the
>>> process and work backwards from there (if there is interest). For
>>> example, I would like to see more non-vendor eyeballs on the EE TCK
>>> java sources and have a way for bug reports to be opened (that include
>>> patches for the TCK). This doesn't have to be the entire TCK but
>>> would include the test classes.
>>>
>>> I also agree that ambiguities in the spec, should be discussed and
>>> improved. I see this as a related issue and am just guilty as others,
>>> for remaining silent on some issues. I think that this could be
>>> improved, if we all want to put effort into it. I think part of this,
>>> could be helped with phone call meetings (either quarterly or when
>>> requested).
>>>
>>> I would also like to see us get to a point, where we agree that the
>>> priority is delivering the best specification for users and achieving
>>> more portability between vendor implementations. Sometimes it seems
>>> that we instead push that our (vendor) implementation is the correct
>>> way (when ambiguities come up for discussion).
>>>
>>> Scott
>>>
>>>
>>> Regards,
>>> Ollie
>>>
>>> [0] https://hibernate.onjira.com/browse/HHH-1134
>>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=322579
>>> [2] https://hibernate.onjira.com/browse/HHH-6896
>>>
>>> Am 17.07.2012 um 20:36 schrieb Harald Wellmann:
>>>
>>> Am 17.07.2012 11:22, schrieb Oliver Gierke:
>>>
>>> Where can one get access to the standalone version of the JPA 2.0
>>> TCK?
>>>
>>>
>>> The TCK is still closed source, AFAIK.
>>>
>>> Over the past two years, I've found numerous spec-related bugs in
>>> all 3
>>> certified JPA 2.0 implementations (Eclipselink, Hibernate,
>>> OpenJPA) that
>>> should have been caught by the TCK.
>>>
>>> Some 18 months ago, when there was not even a public mailing list, I
>>> sent a request to the write-only list jsr-317-feedback_at_sun.com to
>>> release the TCK to the public.
>>>
>>> There is also the sad story of a fourth persistence provider who has
>>> given up on certification after trying in vain to get access to
>>> the TCK:
>>>
>>> http://datanucleus.blogspot.de/2011/01/jpa-tck-request-and-jpa21.html
>>>
>>> It is good to see that the current JCP is more open than former
>>> versions, but of course a community process that really deserves the
>>> name would open source all TCKs for all JSRs, no exceptions.
>>>
>>> 2. How can we actually help out to improve the TCK?
>>>
>>> Well, we can't as long as the TCK isn't open. That's the main
>>> point why
>>> it doesn't make sense to keep it closed.
>>>
>>> The CDI TCK has been Open Source from the very beginning, part of the
>>> same Java EE 6 umbrella release and governed by the same JCP.
>>>
>>> I really don't see why this shouldn't work for JPA just as well.
>>>
>>> Best regards,
>>> Harald
>>>
>>>
>>>
>>>
>>>
>>> Cheers, Ollie
>>>
>>> [0] https://bugs.eclipse.org/bugs/show_bug.cgi?id=322579 [1]
>>> https://hibernate.onjira.com/browse/HHH-6896 [2]
>>> http://jcp.org/en/jsr/detail?id=317
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> mailto:matthew_at_matthewadams.me
>>> skype:matthewadams12
>>> googletalk:matthew_at_matthewadams.me
>>> http://matthewadams.me
>>> http://www.linkedin.com/in/matthewadams
>>>
>>