Apache Tika Bundle Laravel Package

Product Decisions This Supports

• Whether "searchable uploads" belongs on the roadmap. Apache Tika is the standard answer to "extract text and metadata from any file a user throws at us" (PDF, DOCX, XLSX, PPTX, ODT, HTML, images, email). This bundle is the Symfony wiring for the vaites/php-apache-tika client, so it directly informs scoping for a document ingest feature in a CMS/DAM/eZ Platform context.
• Build vs. buy vs. wrap for content extraction. The package reveals a three-layer decision: Tika (Java server) does the parsing, a PHP HTTP client talks to it, and a thin bundle provides DI/config. The PM decision is really "do we own a Java service?" — this bundle is only the cheapest possible answer to the third layer.
• Retrieval/RAG and AI feature feasibility. If the roadmap includes semantic search, summarization, or an assistant over customer documents, text extraction quality is the upstream dependency. Tika gives broad format coverage without per-format engineering.
• Content migration and audit tooling. Bulk-extract text/metadata from a legacy repository to validate migration completeness, detect corrupt assets, or classify documents before re-import.
• Compliance and records management. MIME-type detection and metadata (author, created/modified dates, embedded EXIF) support retention policies, PII discovery, and "what did we actually receive?" audits.
• Vendor/fork governance decision. The package is listed as ezsystems/apache-tika-bundle while its README, badges, and Composer name are all jolicode/apache-tika-bundle — a renamed/absorbed fork. The PM takeaway: this is not a supported upstream. Adoption implies a fork-and-own decision, not a dependency decision.

When to Consider This Package

Consider it only as a reference implementation or a bundled starting point, and only when:

• You are already on a Symfony application (Symfony 2/3 era) that consumes vaites/php-apache-tika directly and you want the service definition/config boilerplate handed to you.
• You accept that the repo is archived, has ~2 stars, zero dependents, and no maintainer — meaning you will vendor it, audit it, and own it forever.
• Your scope is small and internal: a handful of formats, low throughput, tolerant latency, no SLA.
• A Tika server (JVM) is already running or is acceptable to operate in your infrastructure.
• You're prototyping extraction quality before committing to a build.

Look elsewhere when:

• You're on Laravel. This is a Symfony Bundle, not a Laravel package — it will not register in a Laravel app at all. In Laravel you'd use vaites/php-apache-tika directly inside a service provider; the wrapper is roughly a few dozen lines of config, so the bundle buys you nothing.
• You need support, security patching, or a maintenance commitment. Archived + zero dependents means no CVE response path.
• You need modern PHP/Framework compatibility (PHP 8.x, Symfony 5/6/7). Assume breakage and plan a rewrite.
• Throughput or scale matters. Running a JVM sidecar per environment plus HTTP round-trips is an ops burden; at volume, a managed extraction service (cloud document-AI APIs) or a queue-backed async pipeline is a better product bet.
• You only need one or two formats. A direct library (smalot/pdfparser, PhpSpreadsheet, PhpWord) removes the Java dependency entirely — fewer moving parts for the same user outcome.

Practical recommendation: treat this as a specification, not a dependency. The capability (any-format text + metadata extraction) is genuinely valuable; the package is not. Budget an afternoon for a thin in-house wrapper around the underlying client, or evaluate a managed API, rather than accepting an archived fork into your supply chain.

How to Pitch It (Stakeholders)

For executives: We're evaluating how to make user-uploaded documents searchable, summarizable, and auditable. The underlying technology (Apache Tika) is a mature, industry-standard extractor covering dozens of formats, and it's free. However, this specific package is an archived Symfony bundle with no maintainer and no users — it is not something we should ship as a dependency. My recommendation is to adopt the capability, not the package: either build a small internal adapter (low effort, low risk) or buy a managed extraction API if scale or compliance demands it. Decision needed: do we accept operating a small Java service, or pay for a managed one?

For engineering: The bundle is a thin Symfony DI wrapper around vaites/php-apache-tika, which itself is an HTTP client for a Tika server (JVM). It is archived, Symfony-2 era, and won't run on our stack — and it's a Bundle, so it's irrelevant if the target app is Laravel. Two viable paths: (1) depend on the underlying client directly and wire it ourselves (~1 service provider, no Java changes), or (2) call a managed document-extraction API and skip the JVM entirely. Either way, extraction should run async behind a queue, with MIME detection, size limits, and a per-format fallback path.

Ask: Approve a timeboxed spike (1–2 days) to validate extraction quality against our top 10 real documents on both paths, then pick one. Do not add this package to the dependency tree pending that spike.