fix(apache-tika): handle upstream's switch from jar to zip distribution

Apache Tika 4.0.0 stopped publishing tika-server-standard as a standalone
executable jar and now ships it as a zip: the jar inside is a thin launcher
whose manifest Class-Path resolves ~150 dependencies from a sibling lib/
(and plugins/) directory, so downloading just the jar 404s and, even if it
didn't, would no longer be runnable on its own.

Both install and update now use fetch_and_deploy_from_url (already used by
several other scripts in this repo, e.g. ct/technitiumdns.sh) to fetch and
extract the whole archive in place, instead of hand-rolling curl+unzip.
update_script() also passes CLEAN_INSTALL=1 so a later update replaces the
lib/ tree wholesale rather than layering a new version's jars on top of an
old one's.

Verified by running the real ct/apache-tika.sh (via build.func/tools.func
pulled live from this repo's main) against a live LXC container previously
on 3.3.2: it downloads and extracts the 4.0.0 zip, starts the service, and
`java -jar tika-server-standard.jar` answers on port 9998 with
"Apache Tika 4.0.0".

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Author: Munza2020

ct/apache-tika.sh

@@ -35,11 +35,15 @@ function update_script() {
     msg_ok "Stopped Service"
 
     msg_info "Updating ${APP} to v${RELEASE}"
-    cd /opt/apache-tika
-    curl -fsSL -o tika-server-standard-${RELEASE}.jar "https://dlcdn.apache.org/tika/${RELEASE}/tika-server-standard-${RELEASE}.jar"
-    mv --force tika-server-standard.jar tika-server-standard-prev-version.jar
-    mv tika-server-standard-${RELEASE}.jar tika-server-standard.jar
-    rm -rf /opt/apache-tika/tika-server-standard-prev-version.jar
+    # As of 4.0.0, upstream ships tika-server-standard as a zip instead of a
+    # standalone jar: tika-server-standard-<version>.jar inside it is a thin
+    # launcher whose manifest Class-Path depends on a sibling lib/ (and
+    # plugins/) directory that has to move in lockstep with it.
+    # fetch_and_deploy_from_url handles the zip/tar/deb extraction itself;
+    # CLEAN_INSTALL=1 replaces the whole directory instead of leaving the
+    # previous version's lib/ jars mixed in with the new ones.
+    CLEAN_INSTALL=1 fetch_and_deploy_from_url "https://dlcdn.apache.org/tika/${RELEASE}/tika-server-standard-${RELEASE}.zip" /opt/apache-tika
+    mv "/opt/apache-tika/tika-server-standard-${RELEASE}.jar" /opt/apache-tika/tika-server-standard.jar
     echo "${RELEASE}" >/opt/${APP}_version.txt
     msg_ok "Updated ${APP} to v${RELEASE}"
 

install/apache-tika-install.sh

@@ -35,11 +35,14 @@ msg_ok "Installed Dependencies"
 JAVA_VERSION="21" setup_java
 
 msg_info "Installing Apache Tika"
-mkdir -p /opt/apache-tika
-cd /opt/apache-tika
 RELEASE="$(curl -fsSL https://dlcdn.apache.org/tika/ | grep -oP '(?<=href=")[0-9]+\.[0-9]+\.[0-9]+(?=/")' | sort -V | tail -n1)"
-curl -fsSL "https://dlcdn.apache.org/tika/${RELEASE}/tika-server-standard-${RELEASE}.jar" -o tika-server-standard-${RELEASE}.jar
-mv tika-server-standard-${RELEASE}.jar tika-server-standard.jar
+# As of 4.0.0, upstream ships tika-server-standard as a zip instead of a
+# standalone jar: tika-server-standard-<version>.jar inside it is a thin
+# launcher whose manifest Class-Path depends on a sibling lib/ (and
+# plugins/) directory that has to be deployed alongside it -
+# fetch_and_deploy_from_url handles that extraction.
+fetch_and_deploy_from_url "https://dlcdn.apache.org/tika/${RELEASE}/tika-server-standard-${RELEASE}.zip" /opt/apache-tika
+mv "/opt/apache-tika/tika-server-standard-${RELEASE}.jar" /opt/apache-tika/tika-server-standard.jar
 echo "${RELEASE}" >/opt/${APPLICATION}_version.txt
 msg_ok "Installed Apache Tika"