adityamparikh opened a new pull request, #207: URL: https://github.com/apache/solr-mcp/pull/207
> [!NOTE] > Builds on #206 and contains its commit. Merge #206 first; this diff then reduces to the split itself. Happy to fold it into #206 instead if you'd rather the 61 files never land. ### Summary Markdown had no way to carry a dataset. `MarkdownDocumentCreator.create()` always returned a single document, so 61 shows needed 61 files. A file may now hold several records, each its own YAML front matter block followed by its body, and `src/test/resources/shows-markdown/*.md` collapses to one `shows-markdown.md` with the same data and the same 20 fields per show. ### Why the split rule is narrow Markdown has no record separator of its own, and `---` already means two other things — a thematic break, and a setext heading underline. Concatenating files naively fails twice over: commonmark only recognises front matter at position 0, so later blocks become body text, and a mid-file `---` promotes the preceding paragraph into a heading. So splitting engages only when all of the following hold: - the file itself opens with a front matter block — ordinary prose containing a thematic break is never considered; - a boundary is a `---` line preceded by a blank line and followed by a YAML key — a rule followed by prose is not a boundary; - that block is closed by a later `---` — an unterminated block is not a boundary. Anything that is not unambiguously several records still yields exactly one document. The residual ambiguity is documented on `splitRecords`: a document that both opens with front matter and uses a thematic break immediately followed by a `key: value` line will split when it should not. ### What changed - `MarkdownDocumentCreator`: `create()` splits into records and maps each through the existing per-document logic, extracted as `createOne()`; adds `splitRecords()` / `isRecordStart()`. - `MarkdownDocumentCreatorTest`: four cases — two blocks split; one record unchanged; a thematic break does not split; a document without front matter is never split. - `ShowsSampleDataTest`: parses the one file and checks 61 documents against `shows.json`, field for field. Its javadoc no longer refers to `shows.csv`, `shows.xml` or `ShowsSampleDataIntegrationTest`, none of which exist. - `build.gradle.kts`: `-H:IncludeResources` moves from `nativeImageBuildArgs` into the `nativeTest` binary. It had been applied to the shipped native binary and the published `*-native-*` images, which never load a test resource, and filtered out of the test binary, which is the one that reads the fixture. ### Verification `./gradlew spotlessApply build` on Java 25: **BUILD SUCCESSFUL**, 412 tests, 0 failures. The only skips are the 7 pre-existing `OtlpExportIntegrationTest` cases. The regression guard is that the eleven `MarkdownIndexingTest` cases asserting `hasSize(1)` pass **unedited** — if the split rule were even slightly too eager, several would go red. ``` MarkdownDocumentCreatorTest 7/7 pass ShowsSampleDataTest 2/2 pass MarkdownIndexingTest 11/11 pass (unedited) ``` 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_019qWfXJUJ7TU3HJgtNZZq2E -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
