Jasper Rest Client Laravel Package

Technical Evaluation

Architecture fit. sigedi/jasper-rest-client remains a thin, framework-agnostic PHP wrapper over the JasperReports Server (JRS) REST API, and 2.0.0 does not change that. There is still no service provider, facade, config file, or queue integration. Its role is unchanged: an outbound adapter translating "give me this report as PDF/XLSX/CSV" into JRS resource lookups, execution, export, and retrieval. The architectural recommendation stands—hide it behind an internal ReportGenerator interface and keep its classes out of controllers and jobs. If anything, the 2.0.0 major bump reinforces this: an adapter boundary is what makes a breaking upgrade a contained change rather than an application-wide one.

Integration feasibility. The mechanical work is still small—install, configure base URL and credentials, wrap in a service provider, bind an interface, smoke-test against a live JRS. What 2.0.0 changes is the compatibility gate, not the effort. The release explicitly adds Symfony 7 support, which in a Laravel context maps to Laravel 11/12-era dependency trees. Two consequences must be checked before any code is written:

• If our application is on Laravel 10 or earlier (Symfony 6 components), 2.0.0 may be unusable if the PR tightened the constraint rather than widened it. "Allow Symfony 7" frequently arrives alongside a dropped Symfony 5/6 range.
• If we are already on 1.0.0, the major-version bump implies breaking changes we have not been told about. The changelog names three items—encoding fix, Symfony 7, code quality—and "increase code quality" is the vaguest and most likely to include signature or type changes.

Technical risk. The risk profile is marginally improved but structurally unchanged:

• Provenance — partly clarified, not resolved. The prior assessment flagged that the "small enhancements" over Jaspersoft/jrs-rest-php-client were undocumented and un-diffed. We now have a named pull request and an explicit change list for 2.0.0, so the delta is at least inspectable. But that covers the delta within the fork, and the fork-to-upstream delta from 1.0.0 remains unreviewed. This is now a bounded task rather than an unknown: read PR #1 and diff 1.0.0...2.0.0.
• Supply chain — a weak positive signal. A second contributor (@vinceAmstoutz) has appeared, and a PR was reviewed and merged. That is the first evidence of any process beyond a single publisher pushing tags. It is one external contributor and one merged PR, so bus factor is still effectively one and there is still no CI badge, no test count, and no release cadence to rely on. Do not upgrade this to "actively maintained" on this evidence.
• Licensing — unchanged. LGPL-3.0 still requires a legal opinion before shipping, especially if we modify and redistribute or bundle into a distributed appliance. Nothing in 2.0.0 changes this, and the version bump is a good forcing function to get the opinion on record.
• Correctness under load — unverified, and now with a new variable. Nothing in the release notes addresses streaming, timeouts, polling, or large exports. The encoding fix is potentially behavioral: exports containing non-ASCII characters will now produce different bytes than 1.0.0 did. Anything downstream that compensated for mojibake—string sanitisation, iconv passes, template workarounds—must be found and removed, or it will now double-encode.
• Version coupling — improved on the PHP side, still absent on the server side. Symfony 7 support modernises the dependency floor. There is still no stated JasperReports Server support matrix, which is the coupling that actually breaks in production.

Key questions to resolve before commitment (revised):

1. What does the 2.0.0 composer.json actually constrain—does it drop Symfony 5/6, and what are the PHP and Guzzle minimums?
2. What specifically broke to justify 1.0.0 → 2.0.0, and what does "increase code quality" mean in terms of public signatures?
3. What is the fork-to-upstream delta as of 1.0.0, and is upstream still maintained?
4. Which JasperReports Server versions are exercised, and against which PHP and Guzzle versions?
5. Is there any test suite or CI, and does it run against a live server or a mock? (Unchanged by this release, and now more pointed given the code-quality claim.)
6. Does the client support asynchronous job submission and polling, or only synchronous execution?
7. How are large binary outputs handled—streamed to disk or buffered in memory?
8. Who, internally, owns the JasperReports Server instance and the .jrxml report designs?

Integration Approach

Stack fit. Unchanged in principle: isolate the library in a dedicated Reporting module with its own namespace, config, and tests, and expose domain language ("generate the monthly statement PDF"), not JRS concepts. What changes is the version targeting. 2.0.0's Symfony 7 support aligns it with current Laravel, which is good news for a greenfield integration and a potential blocker for an existing Laravel 10 application. Establish the target stack before choosing the version, not after.

Migration path. The prior recommendation—define a narrow internal interface (submit, poll, fetch, list) and keep library types out of every call site—is now demonstrably correct, because we have an actual breaking release to absorb. Two additions:

• Pin exactly. Use "sigedi/jasper-rest-client": "2.0.0" rather than a caret range. With one release per ~18 months and no visible semver discipline, a caret range is a gamble on future behaviour we cannot inspect today.
• Treat the upgrade as a reviewed change, not a routine bump. Read PR #1, diff 1.0.0...2.0.0, and re-run the smoke test. If already on 1.0.0 in production, the encoding fix is the item most likely to alter output in a user-visible way.

Compatibility. Now a three-way check rather than two: PHP version constraints, the Symfony/Guzzle ranges in composer.json (2.0.0 makes this the decisive check for Laravel version eligibility), and the JRS server version in our environment. Add an assertion-level smoke test that a known report renders and that a report containing accented and CJK characters round-trips correctly—the encoding fix is exactly the kind of change that should be locked down by a test rather than trusted.

Sequencing.

1. Dependency triage (half a day, do this first). Read the 2.0.0 composer.json and PR #1. Decide 1.0.0 vs 2.0.0 based on our Laravel version and the nature of the breaking changes. This gates everything below.
2. Proof of concept (1–2 days). Against a non-production JRS instance: authenticate, list resources, run one parameterized report, export to PDF and XLSX, and include a non-ASCII report to validate the encoding fix.
3. Legal and security review (parallel). LGPL-3.0 opinion; credentials via secret manager; confirm TLS verification is enforced.
4. Adapter layer. Service provider, config publishing, interface binding, exception translation into domain error types.
5. Asynchronous execution. Queue-based with explicit timeouts, bounded retries, and idempotency keys so a retried job does not duplicate artifacts.
6. Output handling. Stream exports to object storage; signed URLs rather than proxying bytes through PHP workers.
7. Observability and hardening. Latency and failure-rate metrics, structured logs with report name and parameter hash (not parameters), and a circuit breaker so a JRS outage degrades reporting rather than exhausting workers.

Operational Impact

Maintenance. The maintenance shape is unchanged—little attention to the library, continuous attention to JRS upgrades, report design changes, and source-schema drift—but the outlook is slightly better than assessed previously. A release, a reviewed PR, and a new contributor are the first signs of life since January 2024. That is one data point, not a cadence, and it does not change the planning assumption that we are the maintainers of last resort. Keep the annual decision point: retain the fork, move to upstream, or internalise the client. Note that 2.0.0 arrived roughly 18 months after 1.0.0, so "wait for an upstream fix" is not a viable incident strategy.

Support. Still no vendor. Escalation runs through public Jaspersoft documentation, community forums, and our own engineers. The appearance of a second contributor does not create a support channel—there is no SLA, no issue triage commitment, and no security disclosure process. This remains an explicitly accepted risk with a named internal owner.

Scaling. Unchanged. The client is stateless and cheap; the bottleneck is the JasperReports Server and the report designs. Tune concurrency on the JRS side and mirror it in queue worker counts—adding PHP workers just relocates the queue to the server. Cache identical parameter sets over the same data snapshot ahead of JRS. Plan for reporting as a background workload with an SLA in minutes, not a synchronous page load.

Failure modes to design for and alert on:

• JRS unavailable or slow—circuit break, surface cached or deferred results.
• Authentication expiry or credential rotation breaking every job at once—dedicated service account with monitored rotation.
• Report execution exceeding timeout on pathological parameter sets—hard ceiling and cancellation.
• Memory exhaustion on large exports—streaming and file-size caps.
• Changed output bytes after the encoding fix—regression-test non-ASCII reports and remove any downstream workarounds that were compensating for 1.0.0's mojibake.
• Silent behavioural change from the major bump—pin 2.0.0 exactly and smoke-test on upgrade.
• JRS version upgrade changing response shapes—pin and smoke-test.
• Latent defects inherited from the fork—mitigated only by the adapter boundary and our own tests.

Ramp-up. A mid-level PHP developer is productive with this client in under a day; the surface area is small and the REST semantics are conventional. 2.0.0 does not change the real constraint: report authoring—.jrxml design in Jaspersoft Studio, parameter and datasource modelling, layout debugging—is a separate competency measured in weeks to competence. If the team lacks it, delivery is gated by report design, not by this package. Do not confuse "we integrated the client" with "we can ship reports," and do not read a dependency bump as evidence that the surrounding infrastructure problem has been solved.