build: extract graph-compose-testing into its own module#300
Merged
Conversation
The consumer testing helpers — LayoutSnapshotAssertions (deterministic layout
snapshots) and PdfVisualRegression (page pixel-diff) — shipped inside the engine
jar, forcing Jackson and PDFBox onto every graph-compose consumer. Split them
into their own published, lockstep-versioned module so the core stays lean and
consumers opt in at test scope. Imports are unchanged (same
com.demcha.compose.testing.* packages); only the artifact carrying them moves.
- New graph-compose-testing module (standalone + published, like render-docx),
carrying com.demcha.compose.testing.{layout,visual} plus its Jackson and PDFBox
dependencies. The engine pom drops Jackson.
- New non-published graph-compose-qa module (aggregator child, reactor tail) for
the cross-module suites that need the testing module on the classpath — they
cannot stay in the engine's test scope without a reactor cycle. They reuse the
engine's shared test scaffolding through its existing tests-classifier jar, and
their snapshot/visual baselines move with them.
- Wire both into aggregator/pom.xml, publish.yml (deploy testing), and
cut-release.ps1 (bump + commit testing); the CI build gate now runs the
engine + testing + qa reactor slice on every matrix JDK.
- VersionConsistencyGuardTest now holds graph-compose-testing and
graph-compose-render-docx at the engine version and requires qa to inherit its
version from the aggregator parent.
The examples module used Jackson (EngineDeckData reads the comparative-benchmark JSON) and LayoutSnapshotJson (LayoutSnapshotRegressionExample), both of which it had been getting transitively from the engine jar. With Jackson and the testing helpers now out of the core, the examples build lost them. Add a direct graph-compose-testing dependency — it supplies LayoutSnapshotJson and brings jackson-databind transitively, restoring the examples compile.
The examples module now depends on graph-compose-testing (for LayoutSnapshotJson and the jackson it brings). Like render-docx, that module is a SNAPSHOT not on Maven Central, so the examples-generation job must install it into the local repo after the engine, or dependency resolution fails before compile.
…case exec cut-release.ps1's ShowcaseSync installs only the root artifact before running the examples module via exec:java, but examples also depends on the bumped render-docx and graph-compose-testing SNAPSHOTs, which are not on Maven Central. After the Step-1 version bump they are absent from the local repo, so exec:java fails to resolve them. Install each sibling alongside the root, and mirror the commands in the -DryRun preview.
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.
Why
The consumer testing helpers —
LayoutSnapshotAssertions(deterministic layoutsnapshots) and
PdfVisualRegression(page pixel-diff) — shipped inside thegraph-composejar, pulling Jackson and PDFBox onto every consumer. 2.0 splitsthem into their own module so the core stays lean and consumers add the testing
support at test scope only when they want it. The packages are unchanged, so
imports stay the same; only the artifact that carries them moves.
What
graph-compose-testing— new published module (standalone + lockstep withthe engine, like
render-docx), carryingcom.demcha.compose.testing.{layout,visual}plus its Jackson + PDFBox dependencies. The engine pom drops Jackson.
graph-compose-qa— new non-published module (aggregator child at thereactor tail) holding the cross-module suites that import the testing module.
They can't stay in the engine's test scope: the engine can't test-depend on a
module that compile-depends on it (a reactor cycle). They reuse the engine's
shared test scaffolding through its existing tests-classifier jar, and their
snapshot/visual baselines move with them.
aggregator/pom.xml;the CI build gate now runs the engine + testing + qa reactor slice on every
matrix JDK;
publish.ymldeploysgraph-compose-testingafter the engine;cut-release.ps1bumps and commitstesting/pom.xmlin lockstep (qa inheritsits version from the aggregator, so it needs none).
VersionConsistencyGuardTestextended to holdgraph-compose-testingandgraph-compose-render-docxat the engine version and to requireqato inheritits version.
unchanged.
Tests
./mvnw clean verify -pl .→ BUILD SUCCESS, 1229 tests../mvnw -f aggregator/pom.xml clean verify -pl :graph-compose,:graph-compose-testing,:graph-compose-qa -am→ BUILD SUCCESS — engine +
graph-compose-testing(7) +graph-compose-qa(134).The moved snapshot/visual suites pass against their relocated baselines, so
renders stay byte-identical.