[mgaffigan]

Bumps gradle too, fixes a build error. See each commit for separated intent.

Alternative to #532

[github-actions]

Test Results

131 files  + 1  131 suites  +1   4m 6s ⏱️ +55s
789 tests ± 0  789 ✅ ± 0  0 💤 ±0  0 ❌ ±0 
936 runs  +21  927 ✅ +18  9 💤 +3  0 ❌ ±0 

Results for commit 90852dd. ± Comparison against base commit 4589238.

♻️ This comment has been updated with latest results.

[mgaffigan]

Nothing notable on load test (#525) between 21 and 25 on a couple short runs. Ingest might be faster - but could be measurement noise.

Expanded test suite (#449) passes clean.

[NicoPiel]

Nothing in CI runs on 21 anymore. All the integration configs got renamed to temurin25 and the toolchain is 25, so --release 21 covers API/bytecode but we never actually start the thing on a 21 runtime. Since 21 is still the advertised minimum (oieserver, ps1, install4j), should we keep at least one *-temurin21-* config around?

client/lib/openjfx.jar is still there. It's ~9 MB and server/build.gradle still copies all of client/lib into setup/client-lib, so it keeps getting signed and pushed to every client even though nothing references JavaFX now. The OpenJFX mentions in AboutMirth.java and THIRD-PARTY-README.txt could go with it. Probably also worth a line in the release notes in case some third-party plugin was counting on the client providing JavaFX.

Smaller stuff:

• The Dockerfile says to keep the JDK in sync with .sdkmanrc, but they don't match: Docker has 25.0.4.1_1, sdkman has 25.0.5.0+8, install4j bundles 25.0.5+8.
• ci/README.md lines 73, 74 and 99 still mention the temurin21 configs.
• BrandingConstants.SYSTEM_REQUIREMENTS_URL is unused now, and Frame.java has a double blank line where the javafx import was.
• verification-metadata.xml still has the old jacoco 0.8.8 / mockito-inline / objenesis 2.5.1 / byte-buddy 1.14.13 entries. Harmless, could be pruned.

[NicoPiel]

Clankers trying to sound human sound condescending

[mgaffigan]

Nothing in CI runs on 21 anymore. All the integration configs got renamed to temurin25 and the toolchain is 25, so --release 21 covers API/bytecode but we never actually start the thing on a 21 runtime. Since 21 is still the advertised minimum (oieserver, ps1, install4j), should we keep at least one *-temurin21-* config around?

Yes - updated.

client/lib/openjfx.jar is still there. It's ~9 MB and server/build.gradle still copies all of client/lib into setup/client-lib, so it keeps getting signed and pushed to every client even though nothing references JavaFX now. The OpenJFX mentions in AboutMirth.java and THIRD-PARTY-README.txt could go with it. Probably also worth a line in the release notes in case some third-party plugin was counting on the client providing JavaFX.

Removed.

Smaller stuff:

• The Dockerfile says to keep the JDK in sync with .sdkmanrc, but they don't match: Docker has 25.0.4.1_1, sdkman has 25.0.5.0+8, install4j bundles 25.0.5+8.

SDKMan and eclipse are not currently publishing any two versions that line up that I can find.

• ci/README.md lines 73, 74 and 99 still mention the temurin21 configs.

Updated to obviously fake version numbers.

• BrandingConstants.SYSTEM_REQUIREMENTS_URL is unused now, and Frame.java has a double blank line where the javafx import was.

Removed.

• verification-metadata.xml still has the old jacoco 0.8.8 / mockito-inline / objenesis 2.5.1 / byte-buddy 1.14.13 entries. Harmless, could be pruned.

Removed.

[NicoPiel]

Big fan

[gibson9583]

Looks safe to merge.