Add a lot more versions/variants (more Java versions, more base images, more OpenJDK implementations) #299
Conversation
|
To make sure I get this right - the only problem/bottleneck is the GitHub actions limit? Have you tried reaching out to GitHub and request more capacity considering the impact of this project? Or to the ASF to pick up some of this load? If they won't bother, it should be possible to find a commercial sponsor to contribute the build systems for something like this. |
|
No, the GitHub Actions limits are only an example to help illustrate how large this matrix becomes -- the bigger issue is the load in both maintenance and downstream in the official images program. |
|
I understand the challenge with many different variations to support. One thing I would like to point out is that all the variations mentioned but one are variations of OpenJDK using the Hotspot JVM. From that perspective, they are quite similar (even intentionally, perhaps). But IBM Semeru Runtimes Open Edition is the only JDK variant that uses OpenJDK class libraries with the Eclipse OpenJ9 JVM. As such, it's a valuable variant simply for the significant difference it represents. OpenJ9 can provide different performance characteristics (faster startup and lower memory consumption) that some users might find attractive[1]. While it might not be practical to include all the different variations, adding an IBM Semeru Runtime Open Edition variant might be worth it. I'm the chief architect for IBM Semeru Runtimes and a project lead at Eclipse OpenJ9 (and OMR) so if you have any questions, I would be happy to help. |
|
To continue on the last comment, OpenJ9 has important performance features for s390x and we would really appreciate a docker container with Semeru for 390x which is currently not available. |
|
Honestly, the number of tags showing on the Dockerhub doesn't scare me, nor do I think it's getting out of control. There is a significant value in all the variants. Just as we are picky and only want Corretto on AL, there are specific reasons why others want other Xs on Ys. If the tag list is to be trimmed, I'd argue it can be trimmed horizontally. I.e., :
I see value in having 10.1.8, 10.1 and 10 variants.
I think that folks that use those would need to say, at least, which major version of Tomcat they want, which VM and distro they want. Things are just too different between the variations here, and one truly doesn't care they might as well pick randomly. So this list can be shortened to:
And the last one is questionable as well, as there is enough incompatibilities between minor versions of Tomcat, it should be expected that it's specified. Of course, reducing this list now would throw a wrench to folks who're already using the shortcuts, as they would stop pulling the "latest" things for them. |
|
Regarding the maintenance - I agree that this is a problem, considering just the changes that were needed for yum->dnf support. I think that the current framework is not too maintenance-friendly. I think that if the script was broken up into individual script files for each distro, things would be easier. If a distro stops working, the builds are not published (for that distro) until somebody goes and fixes it. Yes, there will be more duplication in the script code, but it will be offset by not having the as much work in the JQ files, and reduced regressions. |
tianon
force-pushed
the
tomorecat
branch
2 times, most recently
from
76b2c48 to
7190172
Compare
tianon
force-pushed
the
tomorecat
branch
3 times, most recently
from
3ee301f to
ec42dae
Compare
This comment was marked as off-topic.
This comment was marked as off-topic.
|
We are looking to migrate our applications to Spring 6, servlet spec 6.0 and thus Tomcat 10.1.x, however since we are on AWS we would be looking to use Corretto jdk 17 and Amazon Linux. |
tianon
force-pushed
the
tomorecat
branch
2 times, most recently
from
a3bdc70 to
f0a883c
Compare
tianon
force-pushed
the
tomorecat
branch
2 times, most recently
from
f5f54dd to
7163a4f
Compare
tianon
force-pushed
the
tomorecat
branch
3 times, most recently
from
7781cb0 to
43cda0f
Compare
|
Thanks a ton for your work (in progress)! I saw the addition of AL2023 that looks very promising on the RedHat/RPM side. I'd just like to also have Temurin UBI9 (RedHat Universal Base Image 9, a freely distributable base image officially supported by Adoptium) which is available at https://github.com/adoptium/containers for JDK11/17/21. Hopefully that doesn't involve too much work? Thanks in advance. |
|
I'm not really at a place to do that validation work right at the moment, but if someone else could take one of the |
|
Regarding my last request, in case you missed it: infosiftr#2 |
tianon
force-pushed
the
tomorecat
branch
3 times, most recently
from
f0c7cef to
f5744a2
Compare
tianon
force-pushed
the
tomorecat
branch
2 times, most recently
from
44c9b82 to
3e9b135
Compare
tianon
force-pushed
the
tomorecat
branch
3 times, most recently
from
d7dd8a8 to
a563709
Compare
tianon
force-pushed
the
tomorecat
branch
2 times, most recently
from
5ad9531 to
2efa466
Compare
Co-Authored-By: Mike L (Add temurin-ubi9-minimal) <[email protected]>
This implements a large number of new variants based on OpenJDK alternatives listed in https://hub.docker.com/_/openjdk (more Corretto, Temurin, Semeru, SAP, etc).
This is not intended as a target for merging, but rather as a placeholder for discussion (to make the scope of the problem more obvious than it has previously been).
See especially #248 (comment), which summarizes this well:
Example
docker buildcommand to build a version/variant from this PR (adjust as needed for other combinations):docker build --pull 'https://github.com/docker-library/tomcat.git#refs/pull/299/head:10.1/jdk17/semeru-jammy'