[Fall 2023 Wowza upgrade] confirm that we can still build the dlss-wowza plugin module's JAR, update README instructions if needed

[jmartin-sul]

Using the newly built sul-streamengine-stage when deploying test builds...

see also https://github.com/sul-dlss/operations-tasks/issues/3514

part of #57

We should confirm that we can still build the Wowza plugin JAR, both in the Jenkins job that builds the artifact we deploy to VMs, and just using Gradle on a dev laptop. Even if we don't have to touch the plugin code for API reasons, it seems plausible to me that the JAR might need a rebuild, as the current build is just over 3 years old, and may not necessarily be compatible with whatever newer version of the JVM the current Wowza version uses. (or perhaps I'm being overly worried -- I haven't been in Java-land in a while, but I have vague memories of JARs sometimes being too old for a given JVM version?)

See also: https://github.com/sul-dlss/dlss-wowza/blob/master/Jenkinsfile and https://sul-ci-prod.stanford.edu/job/SUL-DLSS/job/dlss-wowza/

[jmartin-sul]

from discussion w/ @aaron-collier and @jcoyne: we should probably target java version 21, which is the most recent LTS release. seems like the servers (jenkins and sul-streamengine-stage) are on java 11 atm.

[jmartin-sul]

as part of this, it may be best to remove the included gradlew and gradlew.bat files from the repo, since they are likely long out of date. slightly less convenient for immediate start, but we should just point devs to the current gradle installer, or advise using brew install gradle.

[jmartin-sul]

paired w/ @aaron-collier and @jcoyne, we think we got the build working locally with the updated gradle wrapper and our local java versions (16 and 21). remaining TODO:

• readme update about upgrading gradlew if first time revisiting project in a while (and/or instructions about installing it from scratch, in which case we could get rid of gradlew) (README: corrections and clarifications of build instructions, formatting touchups #71)
• fix CI build (see below for error) (in progress, see [WIP] Fix Jenkins build #69)
• upgrade java version on jenkins and on new media streaming server to JDK 21, confirm things still work (in progress, see sul-dlss/operations-tasks#3545 and sul-dlss/operations-tasks#3546)
• building with deploymentJar and deploymentJarRelaxed tasks that use with jar or with deploymentJarRelaxed causes errors when running gradlew build or gradlew test, but changing that to e.g. dependsOn(jar) fixes it. is the with superfluous/deprecated/?
  • dependsOn seems documented/supported, whereas it's unclear if with is, so switching to dependsOn

current CI error:

NOTE: Picked up JDK_JAVA_OPTIONS:  --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED


WARNING: An illegal reflective access operation has occurred

WARNING: Illegal reflective access by org.mockito.internal.util.reflection.ReflectionMemberAccessor (file:/ci/home/.gradle/caches/modules-2/files-2.1/org.mockito/mockito-core/3.12.4/f9cdc14ea4a3573c0c0366d47d5ca960be24ddb6/mockito-core-3.12.4.jar) to field java.util.HashMap.table

WARNING: Please consider reporting this to the maintainers of org.mockito.internal.util.reflection.ReflectionMemberAccessor

WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations

WARNING: All illegal access operations will be denied in a future release


> Task :test


edu.stanford.dlss.wowza.TestVerifyStacksToken > verifyTokenAgainstStacksService_filenameNeedsEncoding FAILED

    org.junit.ComparisonFailure at TestVerifyStacksToken.java:103


edu.stanford.dlss.wowza.TestVerifyStacksToken > verifyTokenAgainstStacksService_stacksTokenNeedsEncoding FAILED

    org.junit.ComparisonFailure at TestVerifyStacksToken.java:125


96 tests completed, 2 failed


> Task :test FAILED


FAILURE: Build failed with an exception.


* What went wrong:

Execution failed for task ':test'.

> There were failing tests. See the report at: file:///ci/home/workspace/UL-DLSS_dlss-wowza_update-config/build/reports/tests/test/index.html

[jmartin-sul]

revisiting this after not having touched it since december 2023, because:

• we had one brief wowza streaming outage on june 12 (see https://github.com/sul-dlss/operations-tasks/issues/3568#issuecomment-2195870763)
• update: deferred indefinitely we may once again be (unless i'm misunderstanding) considering allowing consumers besides sul-embed to stream from our prod wowza instance (see e.g. Skip validating the stacks token on SulWowza #53, Always allow streaming access to publicly viewable files stacks#581, media stacks should be able to deliver content to players other than sul-embed media#145)

The first case could be helped by doing the maintenance work to allow builds of this plugin again, because it might be helpful to add debug logging to the plugin to see if it's even getting invoked in outage situations. The second case requires us to be able to get the build working again, because we need to recompile the plugin for any code changs to take effect (of course), and it's better that this compilation happens by automated procedure on shared infrastructure (as opposed to say an individual dev's laptop environment).

(i'd meant to post this last monday, but apparently didn't submit the comment before closing my laptop)

[jmartin-sul]

update: the latest wowza 4.8.x and 4.9.x versions support JDK 21.

for posterity, because i remember it but don't see it captured either in this ticket or in https://github.com/sul-dlss/operations-tasks/issues/3545 -- when we needed to run wowza using JDK 11, but could only seem to compile the auth plugin under JDK 21 (at least on the jenkins VM), @jcoyne had suggested that we build under JDK 21, but set the target runtime to 11. according to the current gradle config for the plugin, we're actually targeting java 8 compatibility (and now i wonder if that has anything to do with the build issues we saw under java 11 on the jenkins server); see

dlss-wowza/build.gradle

Lines 36 to 39 in 5c10c62

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

(update: stumbled on the suggestion about target build version in the related PR: #69 (comment))