Happy for control of the Servlet TCK to pass to the Servlet spec team.
Whether that is as a sub-directory in the existing repo (so we have api,
spec and tck all on the same level) or whether than is in a new repo I'm
not sure.
Does Eclipse or Jakarta have views on the best practise here?
Thinking about it briefly, I'm leaning towards a single repo so we have
a single set of issues and PRs to track. We can use lables to organise
things if required.
At this point this is just a personal view not the consensus view of the
team. What do the other members of the team think?
I'm also torn between a single repo and multiple repo.
PROS:
- simpler
- Can have a single PR that fixes TCK and API at the same time.
CONS:
- I think we want stricter requirements for committing / changing the TCK. Specifically I think we probably need to insist on reviews etc. Can this be done for part of a repo?
- The tests cannot be run by themselves, as there is no reference server to test against. We probably want to come up with some process of running the TCK against several servers to check that it is working before we commit any changes
- We have added some unit tests to the API repo to test some of the internal implementations. This is a good thing to do and we don't want the TCK to stop further testing within the spec.
I think I'm leaning towards a separate repo because I think the build/test/review/commit cycle might be substantially different. But these are weakly held beliefs.
cheers
