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

[gregw]

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

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

[md5]

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]

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]

Will this PR be merged?

[tianon]

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 docker-library/openjdk#211 (comment) and the following discussion for why openjdk:11-jre-alpine doesn't exist (and isn't likely to).

[janblok]

What is needed to get this PR merged?

[gregw]

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

[gregw]

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

[md5]

@gregw This looks promising: usbarmory/usbarmory-debian-base_image#9 (comment)

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

[tianon]

See also docker-library/official-images#4252, especially docker-library/php#666. 😅

[gregw]

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

[gregw]

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]

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]

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

[md5]

@tianon that would be great!

[gregw]

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]

@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]

@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]

@gregw I'll open a docker-library PR