Hi,
On Mon, Oct 21, 2013 at 8:01 PM, Bill Shannon <bill.shannon_at_oracle.com>wrote:
> We might consider adding tests if
> serious portability issues are discovered, but probably not just to make
> the TCK
> better.
>
That sounds reasonable and this perfectly answers my question: for really
serious issues an update can be considered, and otherwise it's for the next
version as per the usual procedure.
Note also that expert group members and licensees have access to the TCK
> before
> the spec is finalized, explicitly for the purpose of helping us ensure
> that the
> TCK is correct and complete. Sadly, that almost never happens.
>
Hmmm, that seems like an area where things could be improved really. Due to
the nature of the TCK it's perhaps not entirely trivial to involve the
community, but it would be great if something could be done here.
As an actual user I may know for instance that certified product Foo AS
version 6.3 has a case where something is clearly a spec violation, so I
know that case is most likely not covered by a TCK test. If I have
submitted a JIRA issue for this, then I would like to be able to ask that
Foo AS version 6.3 is used to test the new TCK before the corresponding new
spec is finalized. If a new test is indeed added to the TCK then this
particular test should thus fail on that product.
Would something like this possible? Asking the community to submit known
failure cases and then testing that a new version of the TCK indeed fails
on those?
>The confidentiality restriction you refer to was removed in the latest
version of the JCP, and should not be >present in the current TCK
licenses. The TCK code is still proprietary, but you can talk about TCK
results.
That's good to hear really. If I'm not mistaken there also was a
restriction that disallowed people with access to the TCK to create their
own set of TCK-like tests. Was this indeed a restriction, and if so has
this been removed as well perhaps?
Kind regards,
Arjan
>
> arjan tijms wrote on 10/20/13 2:34 PM:
> > Hi,
> >
> > I wonder if there is any procedure to address potentially serious
> defects or
> > omissions in the TCK for a given Java EE specification.
> >
> > Hypothetically, suppose that the TCK for JSF tested a bunch of things,
> but did
> > not test the most basic thing (that e.g. JSF actually rendered
> something), or
> > that e.g. JPA would actually be able to persist anything, or Bean
> Validation
> > would actually be able to validate, etc.
> >
> > If I'm not mistaken it's possible for serious spec issues to be
> corrected with
> > an errata, but how does this work for the TCK? Can this be updated
> during the
> > life time of a spec version, and if so what would this mean for products
> that
> > have already been certified using an older version of the TCK?
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> >
>
>