Repository navigation
feat: port the scope-pattern grammar to Java and C# - #496
Merged
Merged
Conversation
…orpus (FR-023 Phase 2 S0a/S0b) Java (Kotlin inherits) and C# gain compilePattern/compileScope/matchesScope matching the TypeScript reference, gated by fixtures/scope-conformance/.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What Changed
com.metaobjects.config.Scope(Java, inherited by Kotlin) andMetaObjects.Config.Scope(C#). Both portcompilePattern/compileScope/matchesScopefrom the TypeScript reference. A pattern with an empty segment, a trailing::or an odd run of:is refused withERR_SCOPE_PATTERN_INVALID. Java splits with a-1limit and matches withMatcher.matches(). C# anchors with\A…\z. Nothing readsscopefrom.metaobjects/config.jsonin either port yet, so no command's behavior changes. This is S0a/S0b of FR-023 Phase 2 (FR-023 Phase 2: share a model across separate repos in Java, Kotlin and C# (Maven/NuGet packaged) #482).ScopeConformanceTest(Java) andScopeConformanceTests(C#). Both run the sharedfixtures/scope-conformance/corpus. Each also pins its port-specific guard (Java trailing-empty-segment, C# trailing-newline anchor), because the corpus has no invalid-pattern case.CHANGELOG.md,docs/CONFORMANCE.md,docs/features/metadata-sources.mdand the two fixture READMEs. The scope-conformance row now shows Java, Kotlin and C# as running the corpus, and the stale "no runner yet" claims are removed.Validation
Risk Assessment
✅ Low: The change is a small, pure library port with no I/O and no callers yet. I traced it against the TypeScript and Python references: splits keep empty segments, the same metacharacters are escaped, the patterns match the whole name, and include/exclude work the same way. The shared corpus gates it, and separate tests cover invalid patterns.
Testing
The reported failure was the 30-minute stryker mutation gate being killed by SIGTERM (exit 143) in earlier runs. It was a harness timeout, not a code defect: the diff touches no TypeScript file, and the same command passed on re-run (mutation score 56.37, above the break threshold of 35). The new Java and C# Scope classes run the shared scope corpus. They also pin the adversarial cases the corpus lacks: empty pattern, empty segment, trailing
::, odd colon run, trailing newline in the name, and a star next to a metacharacter. The full C# conformance suite and the full Java metadata module are green. Only text and command output are available as evidence because the change has no UI. The Kotlin port inherits the Java loader.::, odd colon run) are refused with ERR_SCOPE_PATTERN_INVALID in Java and C#Evidence: ci-local ts-fast/ts-unit passing run log
Pipeline
Updates from git push no-mistakes
✅ **Intent** - passed
✅ No issues found.
✅ **Rebase** - passed
✅ No issues found.
server/java/metadata/src/main/java/com/metaobjects/config/Scope.java:62- The Javadoc on Scope.Compiled said 'Both arrays are already anchored to the whole name'. That is false in Java: compilePattern builds the Pattern with no anchors, and only Matcher.matches() in matchesScope makes the match cover the whole name. A later consumer that trusted the comment and called find() on the public include()/exclude() lists would get substring matches. I rewrote the comment to say the patterns carry no anchors and must be matched with Matcher.matches(), never find(). The C# CompiledScope comment is accurate because its patterns use \A…\z anchors.::, odd colon run) are refused with ERR_SCOPE_PATTERN_INVALID in Java and C#scripts/ci-local.sh --only ts-fast --only ts-unit --strict-toolchainsmvn -o -pl metadata test -Dtest=ScopeConformanceTest(7 tests, 0 failures)dotnet test MetaObjects.Conformance.Tests --filter ScopeConformanceTests(19 passed)scripts/ci-local.sh --only ts-fast --only ts-unit --strict-toolchains(build+typecheck, TS conformance, TS unit suites, mutation gate; exit 0 in 17m41s)dotnet test MetaObjects.Conformance.Tests(full, 2113 passed)mvn -o -pl metadata test(full Java metadata module, 2891 tests, 0 errors/failures)✅ **Document** - passed
✅ No issues found.
✅ **Lint** - passed
✅ No issues found.
✅ **Push** - passed
✅ No issues found.