You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tika.apache.org by ta...@apache.org on 2026/06/29 19:11:46 UTC
(tika) 01/01: TIKA-4730 - post beta-1 fixes
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 <ta...@apache.org>
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