Updates module dependencies#11
Conversation
jottinger
commented
May 8, 2026
- Main focus is on bytebuddy, BUT
- Also updates other dependencies to update CVE issues
* Main focus is on bytebuddy, BUT * Also updates other dependencies to update CVE issues
|
Found it: it's the currentspeedbenchmark, being run from the wrong project, from the looks of it. |
…ench to v2 The Performance Smoke Check has been silently broken on every PR since v1.6 Phase F moved CurrentSpeedBenchmark from src/test/ to the new benchmarks/ Maven module. The job survived only because it runs on `pull_request` events, not `push`, so my v1.6.0 release commits never tripped it. The first external PR (jottinger #11) exposed the breakage with a misleading-looking ClassNotFoundException. Two layers of breakage: 1. Workflow targeting — the perf-smoke and benchmark-diff jobs ran `mvnw -DskipTests test-compile` against the root module and invoked exec-maven-plugin with `-Dexec.classpathScope=test`, expecting the benchmark class on the root project's test classpath. After Phase F the class lives in benchmarks/src/main/java/, so the load fails. Both jobs now run from `-f benchmarks/pom.xml` (compile, not test-compile; main scope, no classpathScope=test). Artifact upload + cache paths move from `target/benchmarks/...` to `benchmarks/target/benchmarks/...`. An additional `Install root artifact` step puts io.github.demchaav:graphcompose:1.6.0 into the runner's local m2 so benchmarks/ can resolve its dependency. 2. Stale CV references in benchmarks/ source — CurrentSpeedBenchmark and FullCvBenchmark imported `CvTemplateV1` (deleted in Templates v2 along with the legacy CV / cover-letter classes) and `CvDocumentSpec` for benchmark fixtures. CanonicalBenchmarkSupport now exposes a v2 `canonicalCv()` returning a `CvSpec` (mirroring the canonical spec used by PresetVisualParityTest, including the "Projects" module that ModernProfessional's `main` slot declares). Both benchmarks switch to `ModernProfessional.create(BusinessTheme.modern())` driving a `DocumentTemplate<CvSpec>`. Invoice + proposal scenarios are unchanged — InvoiceTemplateV1 / ProposalTemplateV1 and their V1 spec types still exist on the canonical surface. Verified locally: `./mvnw -f benchmarks/pom.xml clean compile` green; `./mvnw -f benchmarks/pom.xml exec:java -Dexec.mainClass=com.demcha.compose.CurrentSpeedBenchmark -Dgraphcompose.benchmark.profile=smoke` reports "Performance gate passed for profile smoke" and writes a CSV report to benchmarks/target/benchmarks/current-speed/. Architecture + documentation guard suite still 30 / 0 / 0 / 0.
|
Update — the Performance Smoke Check failure on this PR was actually a pre-existing issue in our CI workflow, not anything in your dependency bumps. Root cause. During v1.6 we moved the benchmark suite (including Fix landed on
Could you rebase this PR on the latest Two follow-up questions on the diff itself, unrelated to the CI red:
|
|
Hi @jottinger — quick update. Based on issue #8 and the work in this PR + #12, I've decided to commit GraphCompose to a Java 17 baseline for the v1.7 release. To get there cleanly I've consolidated everything into a single feature branch — PR #14 ( CI on Temurin 17 is green: 785 / 0 / 0 / 0 across architecture/documentation guards, build+test, performance smoke, and examples generation. I'm closing this PR in favour of #14 — your work isn't lost, it's the foundation of #14. Thank you for the clean diff and the patient debugging on the byte-buddy / Java 25 piece. Looking forward to more PRs. |
|
Consolidated into #14. Thank you. |