tomcat icon indicating copy to clipboard operation
tomcat copied to clipboard

Added openj9 builds

Open smurfy opened this issue 4 years ago • 8 comments

Closes #247

Adds openj9 builds of tomcat based on ibm-semeru-runtimes

smurfy avatar Oct 28 '21 14:10 smurfy

Imho it would be great it this was updated to add Java 17 and merged.

PascalSchumacher avatar Dec 17 '21 13:12 PascalSchumacher

It seems ibm-semeru-runtimes just added 17 images, this mr predates this. I will update the MR shortly.

smurfy avatar Dec 17 '21 14:12 smurfy

Rebased and ran update.sh to pick up java 17 variants too

smurfy avatar Dec 17 '21 14:12 smurfy

Any news on this?

TheWiresharkGuy avatar Jan 31 '22 09:01 TheWiresharkGuy

It would be great if this was merged.

PascalSchumacher avatar Nov 24 '22 10:11 PascalSchumacher

Sorry, our current "support matrix" is already out of control, so we're still trying to decide the best path forward. :bow:

To give you an idea the scale I'm talking about, we currently support four concrete versions of Tomcat across ~3 versions of Java (both JDK and JRE) on up to three different implementation+distro combinations. That's ~49 different builds of Tomcat, which is then multiplied by the list of supported architectures for each image we're FROM. :grimacing:

If we take this PR to the extended conclusion, that balloons to ~6 versions of Java (again, ~two builds each, JDK and JRE), from ~5 vendors across even more variants -- I have a test branch that includes those full changes, and it takes the matrix of supported versions from 49 all the way up to 228 (which still doesn't factor in the way the matrix expands along the supported architectures axis -- that's just explicit tag combinations that all support at least amd64). Limiting that to just the three LTS versions of Java takes us down to 147, but that's still really unmanageable (even the 49 we're at now is pretty high up there). :face_exhaling:

One thing we've considered is updating the templating to generate all 228 variants, but only officially build/publish one or two "tracks" (perhaps just Temurin, for example). That would take our actual supported list way down, but I wouldn't want to publish that many Dockerfiles unless our automated builds are also testing them, and at 228 we'd be pushing the limits of what GitHub Actions is willing to accept. :scream:

So, as you can see, this isn't as simple as just merging this PR. :disappointed:

tianon avatar Nov 29 '22 00:11 tianon

So @tianon, instead of supporting multiple matrices of java, tomcat, and vendors. What do you think about providing a way for vendors to use this repository as of truth to guarantee the tomcat capabilities against releases managed by other people and organizations?

ptrecenti avatar Nov 29 '22 00:11 ptrecenti

I'm sorry, I'm afraid I'm having trouble parsing what you mean -- can you elaborate on what concrete change you're proposing?

tianon avatar Nov 29 '22 01:11 tianon

Thanks for the push (and for the implementation suggestions!! :bow: :heart:); I'm going to close this now in order to consolidate into https://github.com/docker-library/tomcat/pull/299 :sweat_smile:

tianon avatar May 08 '23 21:05 tianon