Limit external Tomcat & Derby tests to startup verification

[samyoon20]

Summary

Implements startup-only verification for two external tests (Tomcat and Derby). This addresses the roadmap item listed in external/README.md — "Startup-only testing (application startup, but not full runs of app functional testing)" — and tracks issue #7243.

Changes

'external/tomcat/' - server-style startup verification

• test.sh: Replaces ant test (full upstream Tomcat test suite) with a start/curl/stop sequence.
• Builds Tomcat from source with ant, starts the server via catalina.sh start, polls http://localhost:8080/ until it responds, then shuts down. A trap cleanup EXIT ensures the servers always stopped. Exits 0 on success, 1 on timeout.
• test.properties: Adds curl to generic_packages (required for the HTTP readiness check).
  playlist.xml: Keeps tomcat_test at extended level, disabled. Remove disables block to reenable

'external/derby/' — tool-style startup verification

• test.sh: Retains the full build sequence (ant clobber, ant all, ant buildjars) The startup signal is java -jar derbyrun.jar sysinfo — Derby's own JVM diagnostic tool, which exercises class loading and runtime reflection.
• playlist.xml: Adds derby_startup_test at extended level. derby_test_junit_all is at extended level, disabled

Reason

The full upstream test suites test the applications themselves, not the JDK. A failure in a Tomcat or Derby unit test is almost certainly an application-level issue, not a JDK defect. What Adoptium needs to verify is: can this JDK launch this application without crashing? A startup check that's much faster than running entire test suite

This is the first "attempt/implementation" of the startup-only pattern listed in 'external/README.md' as planned improvement

Phase 2 -> extending to the other tests that follow similar patterns

The tool-style pattern extends directly to:

• JaCoCo — mvn install -DskipTests then java -javaagent:org.jacoco.agent.jar -version to verify the agent attaches
• Kafka — remove ./gradlew test; verify the built JAR loads cleanly
• Zookeeper — mvn package -DskipTests then verify the built JAR

The server-style pattern extends directly to:

• WildFly — start standalone.sh, curl management port 9990, stop
• Elasticsearch — ./gradlew assemble already exists in the script; start the node, curl port 9200, stop

Parts assisted by IBM Bob

[samyoon20]

@smlambert Hi! When you have time, could I get a review of the direction I'm heading with the test approach I have for tomcat and derby tests? I have two tests that I used as our standard example that if idea is good, we could apply directly to the other related external tests that are listed above. I used disables so the full suite is preserved but not auto-run in CI. To re-enable the full suite, the only change needed is removing the disables block, test.sh already has the full suite command gated behind $1=full, and the playlist already passes --testtarget full.

https://ci.adoptium.net/job/Grinder/17568/
https://ci.adoptium.net/job/Grinder/17569/

tomcat_startup_test:
The Adoptium JDK compiles tomcat source files
The Adoptium JDK starts the Tomcat JVM process — no startup crash, no missing class
The Adoptium JDK's networking stack handles an incoming HTTP request
curl localhost:8080 returns HTTP 200 → exit 0 → tomcat_startup_test_0_PASSED

derby_startup_test:
The Adoptium JDK compiles Derby source with ant — no compiler crash
The Adoptium JDK runs java -jar derbyrun.jar sysinfo
sysinfo exits 0 → derby_startup_test_0_PASSED