I started thinking through what an S-RAMP TCK impl might look like. Here are some ideas and questions -- feedback appreciated:
IDEAS
- No Overlord dependencies. Rather than using s-ramp-client, etc., test solely "as client" w/ RESTEasy.
- The "core" TCK would cover the spec's "Part 1: Foundation": data model, queries, etc. This would depend on #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
- 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?
- 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.
- License?
- 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?
- In addition to #3, do we need a new JIRA project set up to handle "challenges" from future S-RAMP impls?
- 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.
Comments