Apache Tika Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, unchanged by v1.1.0. jolicode/apache-tika-bundle is a Symfony bundle, and Laravel does not have a bundle system. Laravel consumes individual Symfony components (HttpFoundation, HttpKernel, Console), but it never loads a Bundle class, never runs Extension::load(), and never compiles a ContainerBuilder from third-party service definitions. The bundle's entire value proposition — an apache_tika: config tree, autowired TikaClient service, compiler passes — is inert under Laravel. v1.1.0 relaxes a Composer constraint; it does not add a Laravel service provider, a facade, a config publish path, or any auto-discovery mechanism. The artifact remains structurally unusable in a Laravel application. What actually transfers is the underlying library, vaites/php-apache-tika, which is a plain PHP HTTP client for a Tika Server. So the correct framing is still: we are evaluating a dependency we would bypass, not adopt.

Integration feasibility — one blocker partially cleared, one intact.

So the change is real but narrow: it moves the package from "cannot be installed" to "can probably be installed and still cannot be used." That is a shorter distance to a dead end, not a shorter distance to value.

Technical risk — the package remains the risk, not the capability.

• Abandonment signal: downgraded from "strong" to "present." The prior revision of this assessment called the package effectively dead on the basis of its 2019 release and ~6-year silence. That specific claim no longer holds. v1.1.0 is a community contribution (credited to @Baachi) that was reviewed and merged, which is a heartbeat: it demonstrates the maintainer is reachable and the repo is not archived. It is not a commitment. One merged PR over a multi-year gap does not constitute a maintenance cadence, a roadmap, or a support relationship.
• Zero dependents remains the sharpest indicator. The release does not change this. Not a single public project has taken a production dependency on this artifact, so there is still no downstream bug surface, no integration reports, and no proof it functions in any real deployment — let alone under Laravel.
• Bus factor 1, unchanged. JoliCode maintains it as an internal-utility-grade project. If it breaks, we fork it or we own it.
• Java runtime dependency, unchanged and unaffected by the release. Tika Server is a JVM service. This is an operational cost most PHP shops are not staffed for, and it is entirely independent of which PHP client we choose.
• Untrusted-input attack surface, unchanged. Document extraction is a parser processing user-uploaded files, and Tika has a real CVE history. A constraint-widening release tells us nothing about the Tika Server version the client targets, so the risk of stranding on an unpatched parser is exactly what it was.
• The opportunity: 9.42 score is still misleading. Read it as "document text extraction is a real, under-served need" — true for invoice ingestion, resume parsing, contract review, and RAG pipelines. It is not a statement about this package. Score 0.48 remains the honest signal, though a freshness-dimension bump of a few hundredths would be defensible on the evidence of a merged release. The two numbers measure different things and should not be averaged.

Key questions for the spike (still answerable in one day):

1. Does jolicode/apache-tika-bundle v1.1.0 actually resolve against a Laravel 11 skeleton, and under what PHP constraint? Read the resolver output, not the changelog.
2. Does vaites/php-apache-tika still receive releases, and does its current version support PHP 8.2+? The bundle bump may or may not imply a client bump — confirm independently.
3. What is the minimum viable Tika Server version, and does it clear known CVEs?
4. What formats do we actually need? If it is PDF + DOCX + plain text, a pure-PHP path (smalot/pdfparser, phpoffice/phpword) avoids the JVM entirely and may be sufficient.
5. Do we have anyone who can operate a JVM container in production, or is this a new capability?
6. What is the required latency/throughput per document, and does it justify a separate service tier?

Integration Approach

Stack fit — bypass the bundle, keep the capability. v1.1.0 does not change the ranking. Three options, still ranked:

1. Direct HTTP to Tika Server via Laravel's Http facade. No PHP client dependency at all. We control timeouts, retries, and headers. Least code, least vendor surface, easiest to test with Http::fake(). Recommended.
2. vaites/php-apache-tika directly, wrapped in a Laravel service provider. Worth it only if the client's format-detection and metadata parsing save real work. Accepts a dependency in exchange for ergonomics.
3. jolicode/apache-tika-bundle. Still not viable. The v1.1.0 constraint change removes the installation objection but leaves the architectural one fully intact — there is no code path by which Laravel loads a bundle. If a Symfony sibling service exists, it stays there and we do not mirror it in Laravel.

The honest characterisation of v1.1.0 for our purposes: it makes a package we would not use easier to install.

Migration path — there isn't one, and that is fine. Nothing in the Laravel codebase depends on this bundle, so "migration" collapses to a greenfield integration. If a Symfony service already uses the bundle, treat the Laravel side as an independent consumer of the same Tika Server endpoint, sharing infrastructure but not code. Note that a sibling service bumping to v1.1.0 is their change, not ours, and should not pull us into a shared dependency.

Compatibility. Verify before writing any code:

• Run composer require jolicode/apache-tika-bundle:^1.1 in a throwaway Laravel 11 skeleton to establish what v1.1.0's constraint actually permits — this is now a cheap, decisive test that was not worth running before. Record the result either way; it closes the question permanently.
• Run composer require vaites/php-apache-tika in the same skeleton and read the actual resolution output. Do not trust the published constraint; check it.
• If either client fails to resolve, option 1 (raw HTTP) sidesteps the question entirely.
• Confirm the Tika Server version the client expects matches the one we deploy. Client/server version drift produces silent extraction degradation, not loud errors.

Sequencing. Unchanged — the release is not a trigger to re-order work.

1. Day 1 — spike. Stand up apache/tika in Docker, POST three representative documents (a scanned PDF, a DOCX, a malformed file), measure latency and output quality.
2. Day 2 — decision gate. Compare against a pure-PHP parser on the same corpus. If pure-PHP hits ~85% extraction fidelity on our actual formats, stop here and skip the JVM.
3. Week 1 — adapter. A DocumentExtractor interface with a Tika implementation behind it, bound in a service provider. The interface matters more than the implementation: it lets us swap to pure-PHP or a cloud API later without touching call sites.
4. Week 2 — async. Move extraction onto queued jobs. Never extract synchronously in a request cycle; a 30-second PDF will blow past PHP-FPM timeouts.
5. Week 3 — production hardening. Timeouts, retry policy, dead-letter queue for unparseable files, and structured logging of extraction outcomes.

Operational Impact

Maintenance — still assume full ownership, but the case for a hard fork is weaker. v1.1.0 is evidence that the maintainer will merge reasonable PRs, which is the minimum viable condition for depending on a small package. Budget for: periodic Composer audit failures, a possible fork if the client breaks on a future PHP release, and manual Tika Server CVE tracking. Do not budget for upstream feature work — a project with this release cadence will not deliver one. The PHP client is ~500 lines and replaceable in a day; the Tika Server is the durable commitment.

Support — effectively none, marginally better than none. There is now a demonstrated responsive merge, which is worth something in a security-patch scenario: a CVE fix in the client has a plausible path upstream. There is still no Stack Overflow corpus, no issue-tracker velocity, and no vendor SLA. Any incident remains an internal incident. Acceptable for a well-understood, thin integration; unacceptable if the team expects to escalate.

Scaling — the JVM is the constraint, not the PHP.

• Tika Server is stateless and horizontally scalable, but each replica carries JVM overhead: budget 512 MB–2 GB heap per instance and a ~300–700 MB container image with the JRE.
• Isolate extraction workers from the web tier. A document-parsing JVM competing with PHP-FPM for CPU produces latency spikes that are hard to attribute.
• Rough starting estimate: 50–500 ms per document for typical office formats, multi-second for large or scanned PDFs. At 10 concurrent extractions you are CPU-bound on a single node; plan for a queue depth metric and HPA on queue length, not CPU.
• Rate-limit extraction at the queue boundary. A bulk upload of 10k files will saturate the Tika tier and starve interactive users.

Failure modes — ranked by how badly they hide. Unchanged by the release; none of these are addressed by a constraint bump.

Ramp-up — measured in days, and the cost is not where people expect. A mid-level Laravel developer writes the adapter in a day. The real ramp-up is operational: someone must own a Java service, its heap tuning, its CVE cadence, and its container lifecycle. For a PHP-only team, that is a new capability, not a library install. v1.1.0 does nothing to reduce this — if anything, a team reading the changelog might conclude the package is now Laravel-ready, which it is not, and waste a sprint discovering that. Head that off explicitly.

Bottom line for the decision record: the 0.48 score is accurate and the 9.42 "opportunity" score is describing the problem space, not this artifact. The prior recommendation rested in part on the package being unmaintained since 2019; that specific ground has been withdrawn by v1.1.0, which merged a community Symfony-compatibility contribution. The recommendation itself does not move, because it rested primarily on an architectural fact the release does not touch: a Symfony bundle cannot be wired into a Laravel application. Do not take a dependency on jolicode/apache-tika-bundle in a Laravel codebase. The underlying capability is genuinely valuable; pursue it as a Tika Server behind a DocumentExtractor interface, and gate the whole effort on a one-day spike that proves Tika outperforms pure-PHP parsing on our actual document corpus. Re-review only if upstream ships a Laravel service provider or a framework-agnostic core — neither is on the table today.