search

openshift-s2i / s2i-wildfly

Source-to-Image template for WildFly applications
http://wildfly.org/
Other
73 stars 145 forks source link

move wf15 to jdk11 #182

Closed bparees closed 5 years ago

bparees commented 5 years ago

fixes https://github.com/openshift-s2i/s2i-wildfly/issues/181

openshift-ci-robot commented 5 years ago

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bparees

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files: - ~~[OWNERS](https://github.com/openshift-s2i/s2i-wildfly/blob/master/OWNERS)~~ [bparees] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment
bparees commented 5 years ago

@jamesnetherton do you foresee any issue w/ moving the image to JDK11?

jamesnetherton commented 5 years ago

@bparees We should definitely move to JDK 11.

For my own selfish reasons, would it be too much of a chore to support JDK 8 & 11 (just for the latest WF versions)?. I maintain an image for the wildfly-camel project which uses this project for its base image. I'm trying to track down some details of how well Camel runs on JDK 11, but from what I remember, there were some issues.

bparees commented 5 years ago

For my own selfish reasons, would it be too much of a chore to support JDK 8 & 11 (just for the latest WF versions)?.

would you want to ship 2 distinct images, or one image w/ both jdks and an env var to pick which one to use?

I don't really want to deal w/ publishing another image (and picking another name, and the imagestreams, etc), but obviously bloating an image w/ 2 jdks and the associated user confusion about how to pick the jdk is not ideal either.

bparees commented 5 years ago

(are there known backward compatibility issues that prevent things that worked on jdk8 from working on jdk11?)

jamesnetherton commented 5 years ago

Yeah, 2 distinct images ideally. 1 image with multiple JDKs is a bit sub-optimal as you say.

If it's too much of a pain to maintain 2 images, let's go ahead merge this PR. I can assess the state of things afterwards. I pushed a copy of the JDK 8 image to our own project namespace, so I could always fall back on that if needed.

bparees commented 5 years ago

If it's too much of a pain to maintain 2 images, let's go ahead merge this PR.

ok i'm going to do that, sorry, just don't have the bandwidth to setup the multiple images/tags, especially because this repo runs on a deprecated CI process. We'd be happy for someone in middleware to take over ownership :)