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

jmartin-sul commented 10 months ago

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

part of https://github.com/sul-dlss/dlss-wowza/issues/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?)

jmartin-sul commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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:

[x] 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) (#71)
[ ] fix CI build (see below for error) (in progress, see #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)
[x] 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 commented 3 months ago

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. https://github.com/sul-dlss/dlss-wowza/pull/53, https://github.com/sul-dlss/stacks/pull/581, https://github.com/sul-dlss/media/issues/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)

sul-dlss / dlss-wowza

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