test(release-smoke): external consumer smoke projects for the 2.0 modules#396
Merged
Conversation
… modules Prove the modular 2.0 release works for a real consumer resolving from Maven Central, outside the reactor and with no local install behind it. Six standalone Maven projects (no <parent>, so the reactor never builds them), each verifying one published-artifact scenario: - graph-compose renders a PDF out of the box (the drop-in wrapper); - graph-compose-core alone throws MissingBackendException naming graph-compose-render-pdf, and its dependency tree pulls no PDFBox / POI / ZXing / templates / fonts / emoji (maven-enforcer bannedDependencies); - graph-compose-core + graph-compose-render-pdf render via the ServiceLoader SPI; - graph-compose-templates composes a built-in template through the PDF stack; - graph-compose-testing round-trips a layout snapshot (LayoutSnapshotAssertions); - graph-compose-bundle renders a template, exposes the bundled fonts, and makes the colour-emoji set resolvable. A dual-shell harness (run.sh / run.ps1) runs each project against a dedicated local repository that never receives an install of GraphCompose, evicting the graph-compose-* artifacts before each scenario so they must re-resolve from Central; it prints per-scenario RESULT lines and a machine-readable SUMMARY. Maven's own plugins stay cached (re-downloading them tests Maven, not the release). Not wired into CI — run on demand around a release. Tests: all six scenarios pass against the published 2.0.0 on Maven Central, both warm and with GraphCompose evicted per scenario (graph-compose-core-2.0.0.jar fetched from repo.maven.apache.org confirms Central resolution).
…flow
- Isolated settings.xml (mirrorOf=*) forces every artifact and plugin request
through Maven Central, passed to each scenario with -s, so a scenario can only
pass if the coordinate is genuinely resolvable on Central.
- Hard-fail if the GraphCompose cache directory cannot be evicted, and confirm
io/github/demchaav is gone before each scenario, so a stale cache can never mask
a broken publish.
- Accept a version override (--version / -Version, default 2.0.0) passed as
-Dgc.version; release smoke tests published artifacts only, never a SNAPSHOT.
- Add a workflow_dispatch workflow (.github/workflows/release-smoke.yml) that runs
the harness manually with a version input.
Tests: all six scenarios pass against 2.0.0 on Maven Central through the
Central-only mirror with GraphCompose evicted per scenario
(SUMMARY {"version":"2.0.0","passed":6,"failed":0,"total":6}).
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
1 participant
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
Nothing yet proves the modular 2.0 release works for a real consumer — one that resolves the published coordinates from Maven Central, outside this repository, with no local reactor build behind it. The reactor's own tests build against freshly-compiled siblings, not the artifacts a user actually downloads. This adds that missing outside-in verification.
What
Six standalone Maven projects under
scripts/release-smoke/(each with no<parent>, so the reactor never builds them), one per published-artifact scenario:s1-graph-composegraph-composewrapper renders a PDF out of the boxs2-core-onlygraph-compose-corealone throwsMissingBackendExceptionnaminggraph-compose-render-pdf, and its dependency tree pulls no PDFBox / POI / ZXing / templates / fonts / emoji (maven-enforcerbannedDependencies)s3-core-render-pdfgraph-compose-core+graph-compose-render-pdfrender via the ServiceLoader SPIs4-templatess5-testinggraph-compose-testing'sLayoutSnapshotAssertionsround-trips a layout snapshots6-bundlegraph-compose-bundlerenders a template, exposes the bundled fonts, and makes the colour-emoji set resolvableA dual-shell harness (
run.sh/run.ps1) runs each project against a dedicated local repository that never receives an install of GraphCompose, evicting thegraph-compose-*artifacts before each scenario so they must re-resolve from Central. It prints per-scenarioRESULTlines and a machine-readableSUMMARY {...}. Maven's own plugins stay cached — re-downloading them onto an empty repo tests Maven, not this release. Not wired into CI; run on demand around a release.Tests
All six scenarios pass against the published
2.0.0on Maven Central — both warm and with GraphCompose evicted per scenario. Airtight proof of Central resolution: after eviction,graph-compose-core-2.0.0.jar(867 kB) downloads fromhttps://repo.maven.apache.org/maven2/io/github/demchaav/....SUMMARY {"passed":6,"failed":0,"total":6}.