[WIP] Fix Jenkins build

[jmartin-sul]

Why was this change made?

fix the build, include a JAR file that supports upgrading gradlew (omitted accidentally in #65).

i think the crux of the build fix is the upgraded JVM. in this PR it's a hacky one off installation of OpenJDK 21 in the home dir of the user running the build. in my case on my laptop an old OpenJDK 16 worked. i actually noticed, from the env var printout in the jenkins logs for this PR's successful build, $JAVA_HOME got OpenJDK 21, but $PATH didn't actually get overridden, and the actual java binary in use according to java -version was OpenJDK 11. so it seems that the real heart of the fix for the reflection error mentioned in #60 is the use of later supporting java libraries? 🤷 (i didn't see CLASSPATH defined in the env vars)

How was this change tested?

throw stuff at CI till it goes ✅

Which documentation and/or configurations were updated?

Jenkinsfile, build.gradle

TODO

• squash commits
• build.gradle: remove the commented out with cruft, or back out of the switch to dependsOn. i'm inclined to do the former because: the change was motivated by an error that @aaron-collier and i each ran into on our laptops when building earlier this afternoon. the switch to depenedsOn fixed it for me, but even if i go back to just using with, i can no longer reproduce the error. still, i can't find any documentation anymore on with, but i can for dependsOn, so i suspect this change would get us off an old approach anyway? 🤷
  • discussed w/ @aaron-collier just now, we're both inclined to switch to dependsOn since we can find documentation for that, but not for with.
• work with ops to upgrade the jenkins server's java installation to 21, or if that would break other things, to install something like jenv on the jenkins server so that we can manage multiple java versions more easily. (in progress: https://github.com/sul-dlss/operations-tasks/issues/3545)
• once JDK 21 is available on the jenkins box, remove the env var overrides from Jenkinsfile but leave the debugging output. add jenv invocations to switch to JDK 21 if need be (or otherwise update env var overrides as needed if java on jenkins box isn't globally upgraded).
• leave the --no-build-cache and --no-configuration-cache flags?
  • let's leave for now, and if the builds are unpleasantly slow we can revisit
• instead of specifying --gradle-version=8.4, we could also specify --gradle-version=latest
  • @aaron-collier and i discussed, and we're inclined to use the rule of thumb we use elsewhere in the portfolio: update to the latest if possible, and work backwards to pin on a working version if that breaks the build and we can't fix the build on latest in a timely manner. will leave a comment in Jenkinsfile explaining that a specific version is selectable.
• take this out of draft

[jmartin-sul]

per @rsmith11 (see here), wowza only supports java 11-12. will see if i can pin to an older version of gradle and get the build working with that and java 11.

https://www.wowza.com/docs/wowza-streaming-engine-technical-specifications

[jmartin-sul]

per @rsmith11 (see here), wowza only supports java 11-12. will see if i can pin to an older version of gradle and get the build working with that and java 11.

https://www.wowza.com/docs/wowza-streaming-engine-technical-specifications

A now old (but still viable) suggestion that jcoyne made back when we were on the fall 2023 media work cycle: use Java 21 to do the build, since that seems to work, but try targeting Java 11 as the target for the build's JVM compatibility? We may actually already be doing something like this here, see targetCompatibility in the gradle file:

dlss-wowza/build.gradle

Lines 35 to 39 in d7c396d

	version = artifactVersionString
	java {
	sourceCompatibility = JavaVersion.VERSION_1_8
	targetCompatibility = JavaVersion.VERSION_1_8
	}

To push this forward, we may want to try setting targetCompatibility to the latest Java version that Wowza supports, and seeing whether that 1) builds successfully, and 2) works correctly when deployed to e.g. embed-uat for manual testing of authZ behavior.

To try that approach, we should reopen https://github.com/sul-dlss/operations-tasks/issues/3546