feat(provider-tck): source the spec artifacts from the open-feature/spec submodule

[aepfli]

Part of open-feature/spec#417 (cross-language tracking) via #1829 (Java implementation issue). Language-agnostic artifacts: spec#423.
Stacked on #1837, which is stacked on #1830. Base is feat/provider-tck-in-process-control, so this diff shows only the submodule switch.

Depends on open-feature/spec#423. See "Before merging" below.

What

Moves the three language-agnostic spec artifacts out of this repo and sources them from the open-feature/spec submodule instead.

Was	Now
src/main/resources/features/	copied from spec/specification/assets/provider-tck/gherkin/
src/main/resources/flags/canonical-flags.json	copied from spec/specification/assets/provider-tck/flags/
src/main/resources/openapi/control-api.yaml	copied from spec/specification/assets/provider-tck/openapi/

Why

These are not Java artifacts. They are language-agnostic definitions of the provider contract that every language's TCK must agree on byte for byte, and that backend vendors implement in whatever language their testbed is written in. They only lived in this module because the proof of concept had to start somewhere — the original PR said as much in a NOTE ON THE SOURCE OF TRUTH comment and a README section, both of which this PR replaces with the real thing.

How

Exactly the mechanism tools/flagd-api-testkit already uses for the flagd test harness:

1. exec-maven-plugin at initialize → git submodule update --init spec
2. maven-resources-plugin at generate-resources → three copy-resources executions into src/main/resources/

The copies are git-ignored and carry a do-not-edit note in .gitignore, the POM comment and the README. Changes belong in open-feature/spec and arrive here by bumping the submodule.

Consumers are unaffected. The artifacts are still packaged into the release JAR, @SelectClasspathResource("features") still resolves, and nobody needs a submodule of their own.

Verification

Deleted src/main/resources/{features,flags,openapi} entirely, rebuilt from a clean target, and checked the result against the originals on feat/provider-tck:

OK   features/errors.feature
OK   features/evaluation.feature
OK   features/events.feature
OK   features/lifecycle.feature
OK   flags/canonical-flags.json
OK   openapi/control-api.yaml

Byte-identical after the full round trip, and the in-memory suite still reports 29 scenarios / 26 passed / 3 skipped. Jar contents confirmed to still carry all six files.

That round trip is also why open-feature/spec#423 adds a .gitattributes normalising these assets to LF: without it a Windows checkout of the submodule produced CRLF copies, which would make the published JAR differ depending on who built it. For artifacts whose whole claim is byte-for-byte agreement across languages, that matters.

CI

The provider-tck job added in #1837 now checks out submodules — without them there is no suite to run. The main matrix job already used submodules: recursive.

Before merging

The submodule is pinned to 42b047b9 on open-feature/spec#423's branch, not to a commit on spec's main. The commit is reachable on the remote so CI can fetch it, but this must be re-pinned to main once #423 merges:

git -C tools/provider-tck/spec fetch origin main
git -C tools/provider-tck/spec checkout origin/main
git add tools/provider-tck/spec

Kept as a separate PR from #1837 for exactly this reason — the in-process work has no external dependency and can land on its own timeline.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}