I started thinking through what an S-RAMP TCK impl might look like.  Here are some ideas and questions -- feedback appreciated:

IDEAS

1. No Overlord dependencies.  Rather than using s-ramp-client, etc., test solely "as client" w/ RESTEasy.
2. The "core" TCK would cover the spec's "Part 1: Foundation": data model, queries, etc.  This would depend on #3...
3. One binding-specific TCK per spec-supported binding (only Atom, currently).  This would mostly provide the schema JAXB bindings, marshall/un-marshall, and provide endpoint interactivity for #2.

QUESTIONS

1. How set-in-stone are the spec's section #s?  Can we write the tests referring to the #s and reasonably expect them to stay the same?
2. Any issues with housing it in a new GH repo (Governance/s-ramp-tck), or should it be completely external?  In either case, it should be outside of the actual Overlord S-RAMP project.
3. License?
4. I'm only somewhat familiar with all the Oracle TCK processes, but hopefully OASIS is a bit more straight-foward .  What do we need to know ahead of time, setting ourselves up for possibly providing the actual spec TCK?
5. In addition to #3, do we need a new JIRA project set up to handle "challenges" from future S-RAMP impls?
6. How big of a priority should we assign this task?  To me, it seems fairly high and vital for 1.0.0.Final.  We already know some areas that still need implemented (see [SRAMP-462] S-RAMP 1.0 spec compliance and TCK - JBoss Issue Tracker), but a full TCK is bound to turn up quite a bit more.

This article was generated from the following discussion: The specified item was not found.