Issue #98 Upgrade to JRE-11 and Jetty-9.4.14

appropriate / docker-jetty

Formerly the location of the Docker official image for Jetty

https://registry.hub.docker.com/_/jetty/

46 stars 46 forks source link

Issue #98 Upgrade to JRE-11 and Jetty-9.4.14 #99

Closed gregw closed 5 years ago

gregw commented 5 years ago

Upgrade to JRE-11 and Jetty-9.4.14 for #98

Signed-off-by: Greg Wilkins gregw@webtide.com

md5 commented 5 years ago

I think the .travis-ci.yml file needs to be updated as well: https://github.com/appropriate/docker-jetty/blob/master/.travis.yml#L6-L12

As far as the support matrix for Jetty and what version combinations make sense, I'll have to defer to you, but it seems weird that we're jumping from having JRE 8 as the maximum JRE version on all the Jetty releases to having a JRE 11 upgrade for only Jetty 9.4.

Also, I believe JRE 7 is EOL, so should that also be removed?

Lastly, is it possible to have a Jetty 9.4 + JRE 11 version on Alpine?

gregw commented 5 years ago

I've updated travis-ci.yml

Java11 broke so many things that only the very latest jetty-9.4 is capable of running correctly on it. We will never support 9.3 on JRE11.

As you say, JRE 7 and jetty 9.2 are both EOL, so we could remove them as there will be no more releases of either... unless there is a security problem that we wish to fix... so perhaps leave them a little while longer, but ultimately they can be dropped sooner or later.

There is not openjdk:11-jre-alpine to base a Jetty 9.4 + JRE 11 Alpine on, so I'm guessing that alpine is not appropriate for java11 or not yet available.

janblok commented 5 years ago

Will this PR be merged?

tianon commented 5 years ago

There is not openjdk:11-jre-alpine to base a Jetty 9.4 + JRE 11 Alpine on, so I'm guessing that alpine is not appropriate for java11 or not yet available.

See https://github.com/docker-library/openjdk/issues/211#issuecomment-426708580 and the following discussion for why openjdk:11-jre-alpine doesn't exist (and isn't likely to).

janblok commented 5 years ago

What is needed to get this PR merged?

gregw commented 5 years ago

@janblok I'm investigating the CI failure and hopefully merged soon after that is fixed

gregw commented 5 years ago

@md5 any idea why the gpg step is failing more often than not on CI? Am I free to try other GPG keyservers?

md5 commented 5 years ago

@gregw This looks promising: https://github.com/inversepath/usbarmory-debian-base_image/issues/9#issuecomment-451635505

The "gpg: keyserver receive failed: Cannot assign requested address" error seems like it would jibe with an IPv6-related issue.

tianon commented 5 years ago

gregw commented 5 years ago

Thanks! I'll try the no IPv6 first as it looks simpler than the happy eyeballs

gregw commented 5 years ago

Hmmm I'm having no joy. Need to install dirmngr, but that fails on alpine and on the others it doesn't improve the reliability of the gpg anyway! This failure is not really related to this PR... @md5 can we merge without a clean CI?

md5 commented 5 years ago

This failure is not really related to this PR... @md5 can we merge without a clean CI?

My concern about merging without clean CI is two-fold. The first is that this problem will likely happen on the official images build system as well, though perhaps @tianon has more insight there. The second is that any future PRs will probably also break with this same issue with the same frequency.

I think both of my concerns can be set aside to get this merged, assuming the image will build more reliably on the official images build system.

tianon commented 5 years ago

Would it help if I put up a strawman PR to include pgp-happy-eyeballs into CI here for easier review?

md5 commented 5 years ago

@tianon that would be great!

gregw commented 5 years ago

I merged @tianon 's #101 PR here and we now build in CI, but I'm a bit cautious about downloading and running a script from a private repo! @md5 ?

md5 commented 5 years ago

@gregw I think you're right that the optics could be better, but in this case I think @tianon has as much control over @docker-library, so it is basically the same thing. @tianon is part of @infosiftr, who has partnered with @docker on the Official Images program pretty much from its inception as I understand it. @tianon is one of the primary maintainers of the php image mentioned above, the debian images that we rely on, and a bunch of other official images.

gregw commented 5 years ago

@md5 well I'm happy if you are .... but as you're doing the trusting, I'll let you push the green buttons on both PRs :)

md5 commented 5 years ago

@gregw I'll open a docker-library PR