Fail fast when the e2e docker targets run on a JDK older than 17

[wu-sheng]

Fix make -C test docker silently producing a missing or stale e2e-spring-ai-service jar

Follow-up to #14071, addressing a review finding on test/Makefile.

DOCKER_TARGETS lists docker.e2e-spring-ai-service unconditionally, but the e2e reactor only builds that module under its jdk-17 profile (<jdk>[17,)</jdk>, needed because Spring AI requires Java 17 / Spring Boot 4). The Makefile and the pom disagreed about when the module exists, which gives two failures:

1. Clean checkout on JDK 11 — DOCKER_RULE copies a jar that was never produced:

   cp: .../e2e-spring-ai-service/target/e2e-spring-ai-service-2.0.0.jar: No such file or directory
   make: *** [docker.e2e-spring-ai-service] Error 1
   

2. Existing checkout — the quiet one — build.e2e-service runs clean package, but clean only reaches modules in the reactor. On JDK 11 the module is excluded, so a jar left from an earlier JDK 17 build survives and is packaged into an image tagged with the current commit.

Neither failure names the cause, and the downstream symptom is worse than either. The jar is bind-mounted by path, so when it is absent Docker creates a directory where the file should be and the container dies with:

Error: Invalid or corrupt jarfile /services/app.jar

That mentions neither the module nor the JDK, and it leaves a bogus directory in the tree that a later mvn package then fails to write over.

This refuses at parse time instead, before any work happens:

$ make -C test docker          # on JDK 11
Makefile:56: *** e2e-spring-ai-service requires JDK 17+ for Spring AI / Spring Boot 4;
found Java 11. Set JAVA_HOME to a 17+ JDK, or build the other images by name,
e.g. make docker.e2e-service-provider.  Stop.

The check is -ge 17, mirroring the profile's [17,) rather than pinning exactly 17, so JDK 21 and 25 still build the image — the e2e-test-java-versions matrix runs [11, 17, 25], and an == 17 check would wrongly refuse on the 25 leg.

It is scoped to the goals that actually need the module, so the other four images stay buildable by name on any JDK. Verified across both JDKs:

goal	JDK 11	JDK 17
docker	error	proceeds
docker.e2e-service	error	proceeds
docker.push-e2e-service	error	proceeds
docker.e2e-spring-ai-service	error	proceeds
push.docker.e2e-spring-ai-service	error	proceeds
docker.e2e-service-provider	proceeds	proceeds
docker.e2e-mock-llm-server	proceeds	proceeds
init / no goal	proceeds	proceeds

CI behaviour is unchanged: publish-docker-e2e-service.yaml pins JDK 17 and its make -C test build.e2e-service docker.push-e2e-service invocation still builds and pushes all five images. Confirmed by a real make -C test docker.e2e-spring-ai-service on JDK 17 after the change.

Version parsing was checked against every installed JDK plus the legacy 1.8.x form (1.8.0_322 → 8, not 1); if java is absent entirely the comparison yields no match and the guard fires, which is the safe direction.

• If this pull request closes/resolves/fixes an existing issue, replace the issue number. Closes #.
• Update the CHANGES log.

The CHANGES entry is folded into #14071's existing 11.1.0 bullet rather than added as a separate line, since both are part of the same unreleased change and a build-tooling guard is not a distinct user-facing item.