Use eclipse-temurin:21 as base image

[joggee-fr]

Replace deprecated openjdk:17-jdk-slim-bullseye base image as now considered as deprecated. The eclipse-temurin:21 is based on Ubuntu 24.04 and the Debian package could still be used just like before.

1. Just add adduser to installed packages as needed by the Openfire postinst script.
2. Retrieve Java binary using $JAVA_HOME environment variable.

---

Done some quick tests, setup the server with embedded database, access the admin console and create a test user through XMPP.

Issue describe in PR #6 is still present but it is a first step to upgrade the current Openfire image.
Next step could be to use (very) recent Openfire 4.9.0 release.

[dereckson]

Just a note I've tested 4.9.0 and we've an issue with the Base64 class replacement.

Issue: https://devcentral.nasqueron.org/T2022

Upgrade: https://devcentral.nasqueron.org/D3457

I can still push it to a non-latest 4.9.0 tag if you want to test it.

[joggee-fr]

I have just added a commit to update README.md.
The goal of this PR is just to use an up-to-date OpenJDK base image. Eclipse Temurin project looks like an interesting solution to do this and Java 21 is the last LTS for now.

I hope you could give some tests to my proposition and next, we could investigate on issues regarding Openfire 4.9.0.
BTW, after a very very quick try to use 4.9.0 with eclipse-temurin:21, I didn't (yet?) stumble open the issue you have reported.

[dereckson]

Any specific reason to choose specifically Eclipse Temurin as OpenJDK vendor?

[joggee-fr]

There is no technical reason for Eclipse Temurin among the other alternatives proposed for OpenJDK Docker images. But if I'm right this is the only one supported by a foundation. BTW, the image is based on Ubuntu, a Debian derivative, and allows to keep the same logic for Openfire image build, at least for now.

[joggee-fr]

Gentle ping @dereckson.
Any comment if you had the time to test this PR?

[dereckson]

@joggee-fr Are you available this Monday evening to join Nasqueron operations office hours meeting?

If so, we meet on Jitsi - https://meet.jit.si/nasqueron - Monday 2024-10-14 20:00 CEST (18:00 UTC).
That would allow us to have a discussion on the following questions I've drafted at https://devcentral.nasqueron.org/T2028

My goal is to address the matter for the different Java application images, in addition to Openfire,
because the issue you've found apply for there too.

I wanted to invite you to organize that meeting before, but we had a migration ongoing for 2024-10-01, now it's quieter.

(By the way, I've identified the 4.9.0 issue in base 64 old code, and upstream have now an issue on that)

[joggee-fr]

@dereckson, thanks for the meeting invitation but I will not be available to attend.
Let me know here the conclusions for the base OpenJDK image to use.

IMHO, equivs to fix the issue with the Java runtime dependency in the Debian package is just a (temporary) workaround. Looks like the typical way to build a dedicated Docker image is to install a pre-built source package (if not building it in Docker) delivered in a simple archive like tar.gz. My words are based on theses examples:

• Node.js on Debian Bookworm
• PHP on Debian Bookworm also with an interesting method to avoid installing PHP from Debian packages

[dereckson]

The php configuration seems easier and cleaner than the equivs package.

[joggee-fr]

The php configuration seems easier and cleaner than the equivs package.

Maybe this is something that could be discuss there later. Any conclusion on newer OpenJDK base image for Openfire?

[dereckson]

Discussed it with Angelina and Dorian, we agree it's important to move from OpenJDK.

So let's summarise where we are on this issue.

• @aceppaluni has prepared a comparison of the different JDKs to animate a discussion to choose one
• I've drafted a discussion board here to be used in a meeting at best or async'ly at worst: https://app.mural.co/t/nasqueron8788/m/nasqueron8788/1727358719226/d01e092739ce8e1d912507e80388a50b266056d4?sender=u9ff2d4c61142f15016a53269 (*)
• I put your arguments for Eclipse Temurin there too
• Plan I'd suggest is to create a nasqueron/java base image on DockerHub and you're welcome to maintain it if you wish
  -- That image could so get things like equivs or the package pin
  -- Contributions to upstream would be a good idea
  -- It can then be a base for Tomcat too
• The Openfire image will be more easy to read without any Java tricks on it.

I've also created https://devcentral.nasqueron.org/T2028 to track this activity in our own tracker,
we use a Phabricator instance to coordinate our development.

What do you think?

(*) Drop me a mail at dereckson nasqueron.org and I'll send you an invite so you can edit that document

[joggee-fr]

Thanks @dereckson for the summary.
As I don't consider the equivs as the best solution, I will try to open soon a PR based on this one but installing Openfire using the raw .tar.gz archive. I have looked at Debian postinst and it seems quite easy to reproduce in the Dockerfile build.