This is an automated email from the ASF dual-hosted git repository.
tballison pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tika.git
The following commit(s) were added to refs/heads/main by this push:
new 3b6f64eb2f TIKA-4730 post beta 1 fixes (#2915)
3b6f64eb2f is described below
commit 3b6f64eb2f5c01e45a798b77449e31343364e7fe
Author: Tim Allison <[email protected]>
AuthorDate: Mon Jun 29 17:58:01 2026 -0400
TIKA-4730 post beta 1 fixes (#2915)
---
.github/workflows/docker-snapshot.yml | 30 +++++++
.../pages/maintainers/release-guides/grpc.adoc | 37 ++++++---
.../pages/maintainers/release-guides/tika.adoc | 92 +++++++++++++++++-----
docs/publish-docs.sh | 8 +-
pom.xml | 49 ++++++++++++
5 files changed, 182 insertions(+), 34 deletions(-)
diff --git a/.github/workflows/docker-snapshot.yml
b/.github/workflows/docker-snapshot.yml
index 01b2f334f2..91d0ba4cf5 100644
--- a/.github/workflows/docker-snapshot.yml
+++ b/.github/workflows/docker-snapshot.yml
@@ -25,7 +25,37 @@ on:
- '*.md'
jobs:
+ # Gate: publish snapshot images ONLY for -SNAPSHOT versions. The
+ # maven-release-plugin 'prepare release' commit briefly sets project.version
+ # to the bare release version (e.g. 4.0.0-beta-1) and pushes it to main;
without
+ # this gate that push would publish release-named images to Docker Hub
before the
+ # vote. Release/GA images are published post-vote by docker-release.yml.
+ gate:
+ runs-on: ubuntu-latest
+ outputs:
+ publish: ${{ steps.check.outputs.publish }}
+ steps:
+ - uses: actions/checkout@v6
+ - uses: actions/setup-java@v5
+ with:
+ distribution: 'temurin'
+ java-version: '17'
+ cache: 'maven'
+ - id: check
+ name: Publish only for -SNAPSHOT versions
+ run: |
+ V=$(mvn help:evaluate -Dexpression=project.version -q -DforceStdout)
+ echo "Resolved project.version=$V"
+ if [[ "$V" == *-SNAPSHOT ]]; then
+ echo "publish=true" >> "$GITHUB_OUTPUT"
+ else
+ echo "::notice::Version '$V' is not a -SNAPSHOT (likely a
maven-release-plugin 'prepare release' commit); skipping snapshot image publish
so release-named images are not pushed to Docker Hub before the vote."
+ echo "publish=false" >> "$GITHUB_OUTPUT"
+ fi
+
build:
+ needs: gate
+ if: needs.gate.outputs.publish == 'true'
runs-on: ubuntu-latest
timeout-minutes: 120
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..428bb3a458 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:
@@ -262,10 +288,31 @@ git tag X.Y.Z X.Y.Z-rcN # point GA tag at the same
commit as the winning RC
git push origin X.Y.Z
----
+
-For a prerelease (`X.Y.Z-alpha-N`, `X.Y.Z-beta-N`, etc.) where you don't
-want `:latest` to move and don't want the workflow to auto-fire, skip this
-substep. Trigger the Docker release manually via `workflow_dispatch` instead;
-see the Docker guide.
+For a prerelease (`X.Y.Z-alpha-N`, `X.Y.Z-beta-N`, etc.) the auto-trigger does
+*not* fire (the hyphenated tag is filtered out by `tags-ignore`) and `:latest`
+is intentionally not moved. You still create and push the version tag — the
+Docker workflow needs a git tag to build from:
++
+[source,bash]
+----
+git tag X.Y.Z-beta-N X.Y.Z-beta-N-rcN # point at the winning RC commit
+git push origin X.Y.Z-beta-N
+----
++
+then publish the images manually with `workflow_dispatch`. Do this *after* the
+dist artifacts are live on `downloads.apache.org` (the release Dockerfile
+downloads and GPG-verifies them, so promote dist in the substep above and let
it
+propagate — `workflow_dispatch` skips the auto-wait that the tag-push path
has):
++
+[source,bash]
+----
+gh workflow run docker-release.yml -f tag=X.Y.Z-beta-N -f build_number=1
+----
++
+This publishes `apache/tika:X.Y.Z-beta-N` (+ the immutable `…-1` build pin and
+the `-full`/`tika-grpc` variants); it does not touch `:latest`. See
+xref:maintainers/release-guides/docker.adoc[Releasing Tika Docker Images] for
+the full Docker flow, the tag scheme, and Docker-only rebuilds.
[[troubleshooting]]
== Troubleshooting `release:perform`
@@ -343,15 +390,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/docs/publish-docs.sh b/docs/publish-docs.sh
index 217fd793a1..8657204840 100755
--- a/docs/publish-docs.sh
+++ b/docs/publish-docs.sh
@@ -22,7 +22,9 @@
# Usage:
# ./publish-docs.sh /path/to/tika-site/publish
#
-# Prerequisite: run 'mvn package -pl docs' first to populate target/site/.
+# Prerequisite: build target/site/ first, from the repo root:
+# ./mvnw package -Papache-release -pl :tika-docs -DskipTests
+# (The 'docs' module is only in the reactor under the apache-release profile.)
set -euo pipefail
cd "$(dirname "$0")"
@@ -57,7 +59,7 @@ DOCS_DIR="${PUBLISH_DIR}/docs"
if [[ ! -d target/site ]]; then
echo "target/site/ not found." >&2
- echo "Build the docs first: cd .. && ./mvnw package -pl docs" >&2
+ echo "Build the docs first: cd .. && ./mvnw package -Papache-release -pl
:tika-docs -DskipTests" >&2
exit 1
fi
@@ -70,7 +72,7 @@ sed_atomic() {
local script="$1" input="$2" output="$3"
if [[ ! -f "${input}" ]]; then
echo "${input} not found." >&2
- echo "Re-run the docs build: cd .. && ./mvnw package -pl docs" >&2
+ echo "Re-run the docs build: cd .. && ./mvnw package -Papache-release
-pl :tika-docs -DskipTests" >&2
exit 1
fi
sed "${script}" "${input}" > "${output}.tmp"
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
