launcher-application
launcher-application copied to clipboard
fabric8-launcher
Support both Java8 and Java11
We need to design a mechanism for Java-based runtimes to choose their base version - s2i builder of JDK7 or 8.
First blush, we could surface this as an option when choosing the runtime as a dropdown just like the user may select the version of the runtime itself. A UX issue for us to work through.
This request has come from the business and is tracked there as https://issues.jboss.org/browse/RHOAR-102
Let's use this issue to detail how we accomplish and deliver this in the launcher upstream, leaving JIRA for business/PM tracking.
One way to achieve this easily is to specify the JDK version in the Booster version. That would require zero changes in the frontend and the backend. The only change will be in the booster catalog
For the create flow we can add the versions as a drop-down
Em Qua, 9 de jan de 2019 08:19, Andrew Lee Rubinger < [email protected] escreveu:
And for the create flow?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/fabric8-launcher/launcher-planning/issues/197#issuecomment-452645210, or mute the thread https://github.com/notifications/unsubscribe-auth/AADTdRx-AB9gwqvlVeC3Vx2OqUhWqXicks5vBcI3gaJpZM4Z2s0M .
I'm not sure this is that easy, remember that we are depending on images that normally don't come in different Java version "flavors".
See for example: https://hub.docker.com/r/nodeshift/centos7-s2i-web-app/tags
Sure, but they don't exist now so that would have to be a job for the runtime teams. We'd have to convince them to maintain a list of images for all the Java versions that we want to support.
~And then we still have the versions for the runtimes themselves. So we'd have the different versions for the Vert.xs and Spring Boots and Thorntails combined with the different Java versions. That could potentially lead to some combinatorial explosion. (Remember also that JDK 8 is EOL in the coming months and we also have Java 9, 10 and 11)~ Edit: not really relevant, see below.
Ok, so the good news is that all our Java-based apps at least use a single image: "redhat-openjdk18-openshift". The bad news is there's only one, for Java 8. So we'd have to somehow convince whoever manages that to maintain images for all the Java versions we want.
And the different versions for the Runtimes we can hopefully manage inside the creator itself (just like we do now for the Boosters).
Of course we'd have to make sure that certain versions of the Runtimes don't come with minimum requirements for the Java version (I could imagine some not supporting Java 7 anymore for example?)
I expect us to have 2 images available: one each for Java 8 and 11. Could those not be shared for all Runtimes as we presently do for the sole Java s2i one?
@ALRubinger if an official image for Java 11 will be made available then we could do so yes.
It's still combinatorial though, we'll have Java versions and Runtime versions and we'd need to test all combinations of them. The integration test framework that was just merged can take care of that, it´ll just take a helluva lot longer than it already takes now 😂
Beautiful. So we split the build from one long one into several sections. It's the only way to scale the testing.
@gastaldi, we were tracking this issue as a dependency for Launcher to support RHEL 8. Is that accurate?
