This is an automated email from the ASF dual-hosted git repository. tballison pushed a commit to branch TIKA-4730-post-beta-1-fixes in repository https://gitbox.apache.org/repos/asf/tika.git
commit 03f0c756c3b0b9615da3bb2c0f488bdffcbfe7f1 Author: tallison <[email protected]> AuthorDate: Mon Jun 29 15:11:32 2026 -0400 TIKA-4730 - post beta-1 fixes --- .../pages/maintainers/release-guides/grpc.adoc | 37 +++++++++---- .../pages/maintainers/release-guides/tika.adoc | 63 ++++++++++++++++------ pom.xml | 49 +++++++++++++++++ 3 files changed, 122 insertions(+), 27 deletions(-) diff --git a/docs/modules/ROOT/pages/maintainers/release-guides/grpc.adoc b/docs/modules/ROOT/pages/maintainers/release-guides/grpc.adoc index 0576d23bb8..5e676f0646 100644 --- a/docs/modules/ROOT/pages/maintainers/release-guides/grpc.adoc +++ b/docs/modules/ROOT/pages/maintainers/release-guides/grpc.adoc @@ -17,16 +17,33 @@ = Releasing Tika gRPC -This guide covers the process for releasing Apache Tika gRPC components. - -== Prerequisites - -// TODO: Add prerequisites - -== Release Process - -// TODO: Add release steps +`tika-grpc` has no separate release cycle. Its Maven artifact — the slim +`tika-grpc` jar — is built, signed, and deployed to Maven Central as one module +in the normal Apache Tika reactor release. Its runnable form is the +`apache/tika-grpc` Docker image. There is no `tika-grpc` archive on Apache dist +by design; see +xref:maintainers/release-guides/release-artifacts.adoc[Release Artifacts: What +Goes Where] for the rationale (the runnable layout bundles every pipes plugin +and is too large to publish as a mirror artifact). + +== What ships where + +* *Maven Central* — the slim `tika-grpc-<version>.jar` (plus pom, sources, + javadoc, and `.asc` signatures), for embedding the gRPC server in a + Maven/Gradle build. Deployed with the rest of Tika via `release:perform`. +* *Docker Hub* — `apache/tika-grpc`, the ready-to-run server image, built from a + `-Pdocker` Maven layout and published by `.github/workflows/docker-release.yml`. +* *Apache dist* — nothing. There is no `tika-grpc` archive on dist. + +== Release steps + +There is nothing gRPC-specific to do during the source release: the jar rides +along with the main release — follow +xref:maintainers/release-guides/tika.adoc[Releasing Apache Tika]. Publish the +Docker image after the vote passes, per +xref:maintainers/release-guides/docker.adoc[Releasing Tika Docker Images]. == Post-Release -// TODO: Add post-release steps +Covered by the main release guide (next development version, website/download +links) and the Docker guide (image tags). Nothing gRPC-specific. diff --git a/docs/modules/ROOT/pages/maintainers/release-guides/tika.adoc b/docs/modules/ROOT/pages/maintainers/release-guides/tika.adoc index 4b56944fa5..e93f07cf9a 100644 --- a/docs/modules/ROOT/pages/maintainers/release-guides/tika.adoc +++ b/docs/modules/ROOT/pages/maintainers/release-guides/tika.adoc @@ -176,8 +176,31 @@ Ensure you have valid Maven credentials in `~/.m2/settings.xml`: === Step 10: Upload Distribution Artifacts The release-plugin's antrun task assembles a dist directory at -`target/checkout/target/X.Y.Z/` containing the source zip, app jar, server -tarballs, and parser-package jars (each with `.asc` and `.sha512`). +`target/checkout/target/X.Y.Z/` containing the source zip, the runnable +distribution zips (app, server, eval-app), the pipes-plugin zips, and the +parser-package `-shaded.jar` files. The task writes a `.sha512` and a `.asc` +for each and fails the build if any expected artifact is missing or unsigned. +The slim Maven jars (e.g. `tika-app-X.Y.Z.jar`) are *not* here — they go to +Maven Central, not Apache dist. See +xref:maintainers/release-guides/release-artifacts.adoc[Release Artifacts: What +Goes Where] for the authoritative list and the rationale. + +NOTE: The bin zips and `-shaded.jar` files are `<attach>false</attach>`, so the +build's `maven-gpg-plugin` (which signs only attached artifacts) does not sign +them; the antrun's own gpg step does. If you are cutting a release whose tag +predates that step (anything before 4.0.0-beta-1's fix), sign the staged dir by +hand before committing: ++ +[source,bash] +---- +cd target/checkout/target/X.Y.Z +for f in *.zip *.jar *.tgz; do + [ -e "$f" ] || continue + [ -e "$f.asc" ] && continue # src.zip is already signed by the build + gpg --armor --detach-sign "$f" +done +for a in *.asc; do gpg --verify "$a" "${a%.asc}" || echo "BAD SIG: $a"; done +---- WARNING: At the end of `release:perform` you will see an echo telling you to `scp -r ... people.apache.org:public_html/tika/`. *Ignore that.* It @@ -198,12 +221,15 @@ svn commit -m "Stage Apache Tika X.Y.Z RC<n>" Verify the directory contains all expected artifacts (each with `.asc` and `.sha512`): -* `tika-X.Y.Z-src.zip` -* `tika-app-X.Y.Z.jar` -* `tika-server-standard-X.Y.Z.jar` (and `tika-server-standard-X.Y.Z.zip`) -* `tika-parser-scientific-package-X.Y.Z.jar` -* `tika-parser-sqlite3-package-X.Y.Z.jar` -* `tika-parser-nlp-package-X.Y.Z.jar` +* `tika-X.Y.Z-src.zip` (the source release) +* `tika-app-X.Y.Z.zip` +* `tika-server-standard-X.Y.Z.zip` +* `tika-eval-app-X.Y.Z.zip` +* `tika-parser-scientific-package-X.Y.Z-shaded.jar` +* `tika-parser-sqlite3-package-X.Y.Z-shaded.jar` +* `tika-parser-nlp-package-X.Y.Z-shaded.jar` +* one `tika-pipes-<plugin>-X.Y.Z.zip` per pipes plugin (solr, http, s3, gcs, az-blob, + kafka, csv, jdbc, json, es, opensearch, google-drive, microsoft-graph, … — 15 in 4.x) Also: @@ -343,15 +369,18 @@ When in doubt, drop the staging repo and run `release:perform` cleanly from scratch. It costs ~1 hour but yields a guaranteed single-build set of artifacts. -=== gRPC distribution zip is huge (~600+ MB) - -The `tika-grpc-X.Y.Z.zip` artifact bundles every pipes plugin with its full -transitive closure (microsoft-graph, gcs, az-blob, s3, kafka, etc.) plus -multi-platform native libs (rocksdbjni, netty natives). Several hundred MB -of that is duplication of dependencies already in the root `lib/` -directory. This is a known issue tracked for cleanup before beta — see -the to-fix-before-4.0.0-beta punch list. The release can ship as-is; the -zip is correct, just bloated. +=== gRPC Docker build context is huge (~600+ MB) + +`tika-grpc` is distributed only as the `apache/tika-grpc` Docker image and the +slim Maven Central jar — it has *no* Apache-dist archive by design (see +xref:maintainers/release-guides/release-artifacts.adoc[Release Artifacts: What +Goes Where]). The `-Pdocker` build still produces a `tika-grpc-X.Y.Z.zip`, but +only as the *image build context*, not a published artifact. That zip bundles +every pipes plugin with its full transitive closure (microsoft-graph, gcs, +az-blob, s3, kafka, etc.) plus multi-platform native libs (rocksdbjni, netty +natives), so it runs ~600+ MB, much of it duplicating dependencies already under +`lib/`. The bloat lands in the Docker image, not in a release artifact; reducing +it is tracked for a future release and does not block a release. == Post-Release diff --git a/pom.xml b/pom.xml index 0ccb25e6fa..d0a9958c8d 100644 --- a/pom.xml +++ b/pom.xml @@ -190,6 +190,55 @@ </fileset> </checksum> <checksum file="${basedir}/target/${project.version}/tika-${project.version}-src.zip" algorithm="SHA-512" property="checksum" /> + <!-- + TIKA-4733 follow-up: GPG-sign each staged dist artifact. + The bin zips and parser -shaded.jars are <attach>false</attach>, + so maven-gpg-plugin (which signs only ATTACHED artifacts) does not + produce their .asc; it signs the Maven-Central jars/poms and the + source-release zip only. In 3.x the server bin zip was an attached + "-bin" artifact, so it was signed (and pushed to Central) for free; + 4.x detached it from Central (TIKA-4733), which also detached it from + signing. Without this step the Apache dist artifacts ship unsigned. + Uses the gpg-agent the build already primed when signing the attached + artifacts; failonerror aborts the release if a signature can't be made. + tika-<v>-src.zip is excluded; it already has its .asc from the build. + (If you sign with a non-default key, set -Dgpg.keyname and add a + matching "-u" arg here, mirroring maven-gpg-plugin.) + --> + <apply executable="gpg" failonerror="true" parallel="false"> + <arg value="--batch" /> + <arg value="--yes" /> + <arg value="--armor" /> + <arg value="--detach-sign" /> + <fileset dir="${basedir}/target/${project.version}"> + <include name="*.zip" /> + <include name="*.tgz" /> + <include name="*.jar" /> + <exclude name="*-src.zip" /> + <exclude name="*.asc" /> + <exclude name="*.sha512" /> + </fileset> + </apply> + <!-- + Guard: every staged dist artifact must now carry a detached .asc. + Catches the exact failure this step exists to prevent (a silently + unsigned artifact), in the same fail-loud spirit as the guards above. + --> + <resourcecount property="dist.artifact.count"> + <fileset dir="${basedir}/target/${project.version}"> + <include name="*.zip" /> + <include name="*.tgz" /> + <include name="*.jar" /> + <exclude name="*.asc" /> + <exclude name="*.sha512" /> + </fileset> + </resourcecount> + <resourcecount property="dist.asc.count"> + <fileset dir="${basedir}/target/${project.version}" includes="*.asc" /> + </resourcecount> + <fail message="Release staging has ${dist.artifact.count} dist artifact(s) but ${dist.asc.count} .asc signature(s); a dist artifact was left unsigned."> + <condition><not><equals arg1="${dist.artifact.count}" arg2="${dist.asc.count}" /></not></condition> + </fail> <!-- this spacing is less than ideal, but if you indent here, the vote.txt file will have the leading spaces --> <echo file="${basedir}/target/vote.txt"> From: ${username}@apache.org
