Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jakartaee-tck-dev] Criteria for Replacing TCKs
At our Platform Call yesterday (pre-published minutes are here, https://docs.google.com/document/d/1EJ2ilaPhMnQqa3aw6AmwjRbBPGL3_np4uuwklgfqPZI/edit#), Bill brought up the topic which we've been discussing on this mailing list and the Platform mailing list...  We need a process (criteria) for doing this TCK replacement that we've been discussing.  We all agree that we're not going to do this TCK re-factoring for Jakarta EE 9.  But, we can start experimenting (ie, json-b and json-p) and then starting to figure out what the proper long-term answer should be.  That was Bill's point.  If we're thinking that this TCK re-factoring is a Jakarta EE 10 work item, then let's lay the ground work now so that we can iron out the process before the work actually begins.

So, we started the discussion, and here are the notes we took...
  • Criteria for replacing the TCKs. [BS]
    • Discussed how to ensure that a “refactored” TCK is a sufficient replacement to the original (previous version)
    • Is each individual Spec project responsible to verify the re-factoring?  Is that sufficient? Or, do we need some external checks-and-balances?
    • In the past (J2EE, Java EE), the TCKs were incrementally modified.  Easier to monitor the changes going in.
    • Structured reviews might help ensure consistency.  Participants from Spec Project team, the Platform TCK team, the Spec Project TCK team are required.
    • Common framework for the TCKs?  Or, allow each independent TCK to determine the framework used?  A common framework is probably key to the success of this effort.
    • Defining a common framework would allow each Project to plug in their TCK and be executed as part of the overall Platform TCK.
    • Requirement -- allow the use of the existing TCK tests themselves.  If all of the TCK tests need to be modified just to become part of this new infrastructure, the process will die.  We need the ability to incorporate existing TCK tests. Maybe that’s through some build magic or wrappering of the tests or something...
    • Excellent start to this discussion, but needs much more work.  Who should drive this effort? Platform TCK? An individual TCK (ie. json-b or json-p)?  Group effort? Post to the Platform TCK mailing list and ask for volunteers. (KWS)

You can see there are more questions than answers.  At this point, that's okay.  The main point of this note is to raise awareness of the last bullet.  To get this right, we'll need somebody or some team to help drive this re-factoring effort.  Since the majority of our TCK expertise lies in this team, I said I would post the request here first.  If you have an interest in improving our TCK testing capabilities for Jakarta EE going forward, please consider volunteering.  Thanks!

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter

Back to the top