You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 18e9d2b
Browse filesBrowse the repository at this point in the historyBrowse files
fix(java): green the 5 pre-existing ConformanceTest failures
Closes the four provider-extension-* fixtures plus docs-file-basic
that have been failing on main since the 7.0.0 release tree was
cut. Two distinct fixes:
PROVIDER-EXTENSION fixtures (4 of 5)
====================================
The cross-port conformance corpus declares test-only providers
(cycle-a, cycle-b, duplicate-x, duplicate-x-clone,
depends-on-missing, example-template-briefing) via providers.json
to drive the four provider-extension scenarios. The TS and Python
ports load these via composeRegistry / compose_registry; the Java
runner had no equivalent path and honest-failed every fixture as
"providers.json requires unavailable providers".
With MetaDataRegistry.compose(...) now available (b78e201), the
Java conformance runner can mirror the cross-port pattern:
- Adds a sibling helper class ConformanceTestProviders that
declares the test-only providers (matching the shape of the
TS adapter at server/typescript/.../conformance/adapter.ts and
the Python adapter at server/python/.../conformance_adapter.py).
- Test providers join AVAILABLE_PROVIDERS so the honest-gap
check passes.
- For fixtures whose providers.json names only test-only error
providers (cycle-a, cycle-b, duplicate-x, duplicate-x-clone,
depends-on-missing), the runner invokes compose() on the
resolved provider objects and captures the resulting
MetaDataException as the fixture's "thrown" error. The
existing expected-errors comparison pipeline picks it up
unchanged. The empty meta.empty.json stub is skipped — the
test result is fully determined by the compose-time error.
- For the success fixture (new-subtype-success), the
BriefingTemplate's template.briefing subtype is lazily
registered into the singleton just before the loader runs.
This works because fixtures sort alphabetically and
missing-provider-fails (which requires briefing absent) runs
before new-subtype-success (which requires briefing present).
The alphabetical-ordering rationale is documented in
ensureBriefingRegistered's javadoc.
Compose errors now carry CodeSource.DEFAULT as their ErrorSource
envelope so the conformance runner's buildEnvelope produces
format=code (matching expected-errors.json), not format=json. The
three MetaDataRegistry throw sites in resolveDependenciesStrict /
topologicalSortStrict were updated to use the 3-arg
MetaDataException constructor.
DOCS-FILE-BASIC (1 of 5)
========================
The Author entity in fixtures/conformance/docs-file-basic/input
explicitly re-declares "package": "acme::blog" on the object.entity
even though it equals the root's package. The TS / Python oracles
emit this redundant re-declaration on round-trip; the Java
canonical serializer was suppressing it (the "differs from parent"
heuristic in serializeBody) because Java's effective-package model
couldn't distinguish "author wrote it" from "node inherited it".
Adds a packageAuthored boolean on MetaData that the
CanonicalJsonParser sets when it reads a "package" key from a
node's body. CanonicalJsonSerializer then emits the package key
when packageAuthored is true, even if the value equals the
parent's package. This is the "Task 2 follow-up" that the
existing serializeBody comment called out explicitly. Other tests
(195 in metadata) continue to pass — the new flag is opt-in:
nodes whose package was inferred (not authored) still get the
suppression behavior they had before.
Verification:
- ConformanceTest: 196/196 green (previously 191/196).
- metadata module overall: 724 tests / 0 failures / 0 errors
(previously 724/5/0; my new ComposeRegistryTest 6 tests still
green; same overall test count).
- Full reactor builds clean across all 13 modules.
The remaining 1 failure in the render module (RenderSnapshotTest
[template-generator]) is from the parallel TS workstream's
in-flight template-generator render-conformance fixtures and is
not introduced or exposed by this change.
0 commit comments