Release Artifacts: What Goes Where

tika-parser-scientific-package (and sqlite3, nlp) are "drop-in classpath" artifacts. Sysadmins running tika-server who want a parser added to its classpath grab one fat jar and cp it into /tika-extras/. That’s the use case the shaded jar serves on Apache dist.

A Maven consumer wanting the same parsers does not want a 25 MB jar shaded over their classpath — Maven’s transitive dep resolution gives them the same classes via the module jar + its deps. So Central gets the slim (~10 KB) metadata jar; pom transitive deps do the work.

Mechanism: maven-shade-plugin configured with <outputFile>${project.build.directory}/${project.artifactId}-${project.version}-shaded.jar</outputFile> and <shadedArtifactAttached>false</shadedArtifactAttached>. Shade writes the fat jar to a separate file on disk but does not attach it to the Maven artifact set, so mvn deploy only uploads the slim main jar.

The .zip for each pipes plugin is the runtime drop-in form: unzip into <server>/plugins/<plugin-name>/ and pf4j discovers it at startup. That’s an Apache dist artifact, not a Maven artifact.

The plugin’s jar is on Maven Central for users building atop the plugin API or embedding it programmatically.

Mechanism: maven-assembly-plugin with <attach>false</attach> in each plugin pom (TIKA-4723). Because <attach>false</attach> also skips the local-repo install, each plugin pom additionally runs maven-install-plugin:install-file during the install phase, writing the zip into the local repo at canonical coordinates (<groupId>:<artifactId>:zip:<version>). Sibling modules (tika-pipes-fork-parser, tika-server-*, tika-grpc, integration tests) declare the zip as a test-scope Maven dep and rely on this mechanism to resolve it from the local repo without ever publishing it to Central.

tika-grpc is a standalone gRPC server, parallel to tika-server — not built on top of tika-server-core. It depends directly on tika-core and the parser modules (via tika-parsers-standard-package).

Maven Central gets the slim tika-grpc.jar for users embedding the gRPC server in a Maven build. Apache dist publishes nothing for tika-grpc. Users either pull apache/tika-grpc from Docker Hub or add tika-grpc as a Maven dep.

The release workflow builds the image from a build context it assembles itself (dependency:copy-dependencies for the runtime jars, plus a cp of every pipes-plugin zip and parser-package jar) — nothing there is published as a release artifact. mvn package -Pdocker -pl tika-grpc produces an equivalent runnable tika-grpc-<v>.zip for local debugging only; the image build does not consume it.

tika-grpc expects pf4j plugins for full functionality; starting without plugins logs a warning with a download URL pointing at Apache dist. Most fetcher-dependent RPC calls will fail at runtime if no plugins are present.

tika-server-standard-<v>.jar is the slim runtime jar — its manifest declares Class-Path: lib/ and it expects to be run from a directory that also contains a populated lib/ (and plugins/). Standalone the slim jar can’t run. Maven Central publishes it for embedders who’ll resolve lib/ via Maven dep resolution.

tika-server-standard-<v>.zip is the full assembled distribution: the slim jar + lib/ + the bundled tika-pipes-file-system plugin + a startup script. Apache dist publishes this for sysadmins who want unzip + java -jar.

Dist carries only the .zip: no slim jar, no -bin.tgz, no -bin classifier. The name is tika-server-standard-<v>.zip, consistent with tika-app, tika-eval-app, and the pipes plugins.

Same pattern as the parser packages — Central gets the slim jar (Maven consumers); dist gets the assembled zip with deps under lib/.