Install curl explicitly, and fix the Solr image build context

Review feedback: both healthchecks shell out to curl, but neither Dockerfile installs
it. Both base images do ship curl today, so this was not a live failure:

  solr:8.11-slim              -> /usr/bin/curl, /usr/bin/grep
  tomcat:9-jdk (built image)  -> /usr/bin/curl

The objection is still right, because the probes relied on that by accident and the
failure mode would be misleading rather than obvious: the container would never report
healthy, depends_on: condition: service_healthy would stop dspace-angular from starting
at all, and the autoheal sidecar would keep restarting a container that is fine. Nothing
in the output would point at a missing binary. So the dependency is now explicit in both
images, with a comment saying what breaks without it.

Fixing the Solr image also required fixing its build. `docker compose build dspacesolr`
could not work at all, independently of this branch:

  failed to compute cache key: "/scripts/log4j2.solr.xml": not found

The compose build context was ./dspace/src/main/docker/dspace-solr/, a directory holding
nothing but the Dockerfile, while the Dockerfile copies scripts/log4j2.solr.xml from the
repository root. CI never noticed because .github/workflows/docker.yml builds the same
Dockerfile with the repo root as context - compose and CI were building the image two
different ways and only CI's way worked. Compose now matches CI.

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

Author: MatusBeke

Dockerfile.test

@@ -57,9 +57,13 @@ ENV DSPACE_INSTALL=/dspace
 ENV TOMCAT_INSTALL=/usr/local/tomcat
 # Copy the /dspace directory from 'ant_build' containger to /dspace in this container
 COPY --from=ant_build /dspace $DSPACE_INSTALL
-# Need host command for "[dspace]/bin/make-handle-config"
+# host: needed by "[dspace]/bin/make-handle-config"
+# curl: used by the container healthcheck in docker-compose.yml. The tomcat base image
+#       ships it today, but the probe must not silently depend on that staying true: if
+#       curl went away the container would never report healthy, service_healthy would
+#       block dspace-angular, and autoheal would restart a container that is actually fine.
 RUN apt-get update \
-    && apt-get install -y --no-install-recommends host \
+    && apt-get install -y --no-install-recommends host curl \
     && apt-get purge -y --auto-remove \
     && rm -rf /var/lib/apt/lists/*
 # Enable the AJP connector in Tomcat's server.xml

docker-compose.yml

@@ -209,7 +209,13 @@ services:
       autoheal: "true"
     image: "${DOCKER_OWNER:-dspace}/dspace-solr:${DSPACE_VER:-dspace-7.6.5}"
     build:
-      context: ./dspace/src/main/docker/dspace-solr/
+      # Context is the repository root, matching .github/workflows/docker.yml. The
+      # Dockerfile does `COPY scripts/log4j2.solr.xml`, which lives at the repo root,
+      # so the narrower ./dspace/src/main/docker/dspace-solr/ context used before made
+      # `docker compose build dspacesolr` fail with "/scripts/log4j2.solr.xml: not found"
+      # while CI built the same image fine.
+      context: .
+      dockerfile: ./dspace/src/main/docker/dspace-solr/Dockerfile
       # Provide path to Solr configs necessary to build Docker image
       additional_contexts:
         solrconfigs: ./dspace/solr/

dspace/src/main/docker/dspace-solr/Dockerfile

@@ -37,4 +37,12 @@ RUN chown -R solr:solr /opt/solr/server/solr/configsets
 
 COPY scripts/log4j2.solr.xml /var/solr/log4j2.xml
 
+
+# curl: used by the container healthcheck in docker-compose.yml, which asks the CoreAdmin
+# API whether the "search" core is registered. The solr:*-slim base ships curl today, but
+# the probe must not silently depend on that: without it Solr would never report healthy,
+# service_healthy would block the backend, and autoheal would restart a healthy container.
+RUN apt-get update \
+    && apt-get install -y --no-install-recommends curl \
+    && rm -rf /var/lib/apt/lists/*
 USER solr