Open jmartin-sul opened 1 year ago
jmartin-sul
commented
1 year 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
1 year 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
1 year 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:
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)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 dependsOncurrent 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.htmlrevisiting this after not having touched it since december 2023, because:
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
commented
1 day ago 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 https://github.com/sul-dlss/dlss-wowza/blob/5c10c62f7f8a5f3172482b69c2f2bf58104fe673/build.gradle#L36-L39
(update: stumbled on the suggestion about target build version in the related PR: https://github.com/sul-dlss/dlss-wowza/pull/69#issuecomment-2201121593)
Using the newly built
sul-streamengine-stagewhen deploying test builds...see also https://github.com/sul-dlss/operations-tasks/issues/3514
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?)
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/