Payara 7.2026.8 upgrade plus multiple library updates

[qqmyers]

What this PR does / why we need it: This PR updates multiple libraries used in Dataverse along with updating to Payara 7.2026.8.

Which issue(s) this PR closes:

• Closes https://github.com/IQSS/dataverse-security/issues/135

Special notes for your reviewer: There are a couple fixes for tests to pass because the updated libraries pull in a new XML processor. Using TransformerFactory.newDefaultInstance(); keeps the current one. Alternately we could use the new processor (TransformerFactory.newInstance()) and address the changes (it seems to be hardcoded at 3 spaces indent for pretty printing and I haven't checked for other differences.)
The PR also includes a couple test changes to allow them to pass on Windows - they were hardcoded to a specific line separator or the existence of a /tmp dir.

Lastly, there's an odd comment about jhove 1.34 in the PR - when I initially tried updating to it, there was a commons-compress conflict as some of the jhove modules pulled in an old version. I eventually solved that (by pulling in commons-compress first), but eventually decided to revert to the current jhove. (jhove 1.34 doesn't yet have all the modules packaged for maven and the 1.30 version separated the modules into separate maven dependencies. 1.20.1 is old, but for QDR I decided to stop working on it for now.)

Suggestions on how to test this: Regression testing - nothing should be changed with these updates. (QDR has been testing as well).

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

Is there a release notes update needed for this change?: release notes would need the normal payara version update instructions.

Additional documentation:

[coveralls]

Coverage is 25.024% — QualitativeDataRepository:payara7.2026.6plus into IQSS:develop. No base build found for IQSS:develop.

[Ozoubia]

Hi @qqmyers,
following the topic on Zulip (#containers > Upgrading payara only), I have a question regarding the upgrade. We built the base image from the plain v6.11 tag with only -Dpayara.version=7.2026.6, without any of the code/library changes from this PR. It deploys cleanly on our test instance and basic smoke tests (login, upload, search, metadata exports) pass.
The Payara version was flagged by our IT security, so we cannot wait for the next Dataverse release.
Do you know of anyone running Payara 7.2026.6 in production? And are any of the changes here required at runtime? We're planning to run this combination in production until 6.12 ships.
Thank you in advance :)

[pdurbin]

-Dpayara.version=7.2026.6

For a bit more context, this comes from https://guides.dataverse.org/en/6.11/container/base-image.html#build-instructions

[qqmyers]

The code changes here were due to other library updates, so I suspect that you'd be fine just deploying the newer Payara. You could update the payara bom version and rebuild the Dataverse war, but I'd usually expect compatibility across minor version updates. QDR often uses Payara versions newer than the recommended and have only encountered issues (which then get fixed in PRs we submit) when Payara or one of the libraries they use has had a major change.

[pdurbin]

I just checked with @qqmyers and now I understand better that this PR could have only included an update for Payara. He just happened to include some unrelated library updates plans to roll out.

[Ozoubia]

that's good to know, thank you for the help :)

[pdurbin]

@qqmyers to get the API and JSF tests passing, can you please merge from develop or rebase? I just merged this pull request from @srmanda-cs:

• Container tests failure fix build image locally #12607

[pdurbin]

Looks good! Tests passing! Approved! Thanks, @qqmyers!

It needs to be tested, of course!

[pdurbin]

.8 is out. Jim is taking a look.

[qqmyers]

The payara-bom wasn't updated with this release, so there are no changes from that - just updates to reference 7.2026.8 everywhere.

[qqmyers]

I was incorrect - there is a new payara-bom for 7.2028.8 and it has a change to microprofile that caused a compile error in the recently added DataverseOenApiFilter (in #12439). I was able to fix that, but the build is now failing at on the smallrye plugin and I haven't been able to fix that. One issue may be that the newest payara-bom is not yet on maven central - only the payara repo. Our compile step was getting that but we did not have the payara repo in the pluginRepositories section of the pom. However, adding that, and trying to force the smallrye plugin to use the new microprofile api haven't fixed the issue:
[ERROR] Failed to execute goal io.smallrye:smallrye-open-api-maven-plugin:3.10.0:generate-schema (default) on project dataverse: Execution default of goal io.smallrye:smallrye-open-api-maven-plugin:3.10.0:generate-schema failed: An API incompatibility was encountered while executing io.smallrye:smallrye-open-api-maven-plugin:3.10.0:generate-schema: java.lang.NoSuchMethodError: 'void org.eclipse.microprofile.openapi.models.media.Schema.setExclusiveMaximum(java.lang.Boolean)'

Strangely, smallrye appears to run ok when I trigger it from my IDE.

Any ideas? @beepsoft or anyone else?

[pdurbin]

We'll switch to testing/merging .7 if we can get .8 working by Tuesday.

[qqmyers]

Looks like updating smallrye to the latest works, so this is ready to go again. (I just updated the smallrye-config version and remove a test adding the mp config dependency in the plugin. If those cause issues, I'll revert.)

[qqmyers]

FWIW: SearchIT failed at line 1444 in a prior run because the call to sleepForIndexing had a timeout of 10 seconds and that wasn't long enough. The method being used in UtilIT is called from 60 places, upping the limit would up it for many uses. (Not a bad thing - sleepForIndexing calls once per second and stops as soon as indexing happens so a longer timeout only slows things when needed. In any case - some other PR.