-
Notifications
You must be signed in to change notification settings - Fork 0
Roadmap Upgrade Automation Toolchain
The plan for taking JasperReports Server upgrades from a manual, expert-gated project to a guided, largely automated workflow — scan, plan, execute, validate, with humans approving instead of typing.
Grounded in 16 field-reported upgrade issues (impact/frequency rated from real engagements) and the 4.7→10.1 upgrade playbook. Roughly half the foundation already exists as proven scripts in the jasper-deploy skill.
Every supported customer must move: 8.x and older are already unsupported, 9.0 hits a hard EOL wall 12/31/2027 with Extended Support unpurchasable, and the 10.0 hop (Jakarta, Tomcat 10.1/11, Java 17/21) is the hardest in a decade. Customers below 9.0 must leap-frog multiple hops — multiplying every manual task. See the Upgrade and Migration Hub.
| Tool | What it does | Retires (field issue #) | Existing accelerator |
|---|---|---|---|
| T1.1 Upgrade Readiness Scanner | One command against a live server: detect version/edition, check platform cliffs for the chosen target, inventory drivers + JDBC config (all three locations), fingerprint the WAR against a pristine baseline to enumerate customizations, emit a readiness report + generated hop-by-hop plan | #3, #4, #11, #14 |
doctor.ps1, extract_lineage.py, playbook ladder/cliffs as the rules engine |
| T1.2 Keystore Consistency Validator | Validate .jrsks/.jrsksp presence, ownership, and consistency across machines before any step; carry the keystore; hard-abort any flow that would mint a fresh one |
#1, #16 | Documented failure modes fully mapped (playbook 4a) — codification, not research |
| T1.3 Large Repository Migration Engine | Chunked, resumable export/import: slice by folder, tuned JVM, per-slice verification, retry/resume, source-vs-target reconciliation, audit-events pass | #8, #10 | Existing export/import/promote scripts |
| Tool | What it does | Retires |
|---|---|---|
| T2.1 Customization Diff & Merge Assistant | Three-way merge (old-pristine / old-custom / new-pristine); javax→jakarta codemod for the 10.0 hop; Spring Security config migrator; short review list of true conflicts |
#13, residual #4 |
| T2.2 Configuration Migrator | Maps default_master.properties across eras; driver JAR→property helper; regenerates SSO (LDAP/OAuth2) and SMTP config on the new version |
#2, #5, #6, #3 |
| T2.3 Theme Migration + Visual Regression | Re-apply themes, render representative pages, pixel-diff against baselines — machines catch breakage, not end users | #9 |
| T2.4 Buildomatic Error Assistant | Parse upgrade logs, match stack traces against a symptom→fix knowledge base, answer in plain language | #15 |
| Tool | What it does | Retires |
|---|---|---|
| T3.1 Upgrade Orchestrator | The single front door: scan → plan → approve → execute → validate across all ladder hops, checkpointed rollback at every hop, WAR-permission validation, evidence bundle | #12 + process opacity |
| T3.2 Post-Upgrade Validation Suite | Automated proof: serverInfo assertion, job/alert integrity, fills of the customer's own top-N reports with visual diff, REST compatibility probes, SSO/SMTP probes | #7 |
| T3.3 Fleet Dashboard | Every customer's version vs the EOL clock, risk scoring, upgrade-wave planning — proactive campaigns instead of fire drills | — |
Coverage: all 16 field issues have an owner. (Full mapping table: playbook sec 0.)
| Phase | Scope | Outcome |
|---|---|---|
| 1 (0–3 mo) | T1.1 + T1.2 (both read-only, ship fast, zero execution risk) | No upgrade starts blind; the #1 blocker becomes impossible |
| 2 (3–6 mo) | T1.3 + T2.2 + T2.4 | Remaining Blocker/Common clusters retired |
| 3 (6–12 mo) | T2.1 + T2.3 + T3.1 + T3.2 | End-to-end guided upgrade |
| Continuous | T3.3 + knowledge-base growth | Upgrades run as campaigns |
Read-only first, destructive never-by-default - any-version-in (the ladder is data, one front door) - evidence out (every run produces an attachable report) - offline-capable (air-gapped customers) - knowledge compounds (every field failure becomes a scanner rule or an assistant entry).
The Functionality backlog (playbook sec 0, tooling roadmap) is the authoritative list. Open a feature request naming the tool ID (e.g. T1.2) you want to build against, and see CONTRIBUTING for the definition-of-done.
Canonical sources: the upgrade playbook (field issues + tooling roadmap, sec 0) and the CS recommendations document. Facts stamped 2026-08.