Update Java/base image and added DCE images

[tobias-trabelsi-sonarsource]

No description provided.

[tianon]

Our experience is that set -eux is much more reliable and consistent than using a long && chain -- any particular reason this was switched the other direction in a seemingly unrelated PR?

(Coming here from the downstream review at docker-library/official-images#9631)

[tobias-trabelsi-sonarsource]

Hi @tianon ,
to ease the update of java. we want to stay on alpine but use adoptopenjdk and they are using the && notation

[ghost]

Hi @tianon, I think Tobias' point is that the && chain is directly taken from the Dockerfile of Adoptopenjdk official image which is already accepted by Docker.

We are currently trying to release Sonarqube 8.7 and we are only waiting for the official docker image to be published. I would like to understand whether using long "&& chain" instead of "set -eux" is considered a regression for you, and it's the only issue blocking Docker from public image for Sonarqube ?

If it is, we can discuss with @tobias-trabelsi-sonarsource if we can change back to use "set -eux", or directly use adoptopenjdk/openjdk11 as base image.

[tianon]

The Alpine variants of the adoptopenjdk image were not accepted after a discussion with the maintainer (see Alpine-related discussion points in docker-library/official-images#5710 -- otherwise I would be suggesting you adjust to be FROM adoptopenjdk:11-alpine or similar); this change in particular stands out because it makes the diff significantly larger for no apparent purpose (and in a way that's strictly worse than the previous implementation).

Using FROM adoptopenjdk/openjdk11 will not be acceptable (https://github.com/docker-library/official-images#repeatability).

[ghost]

HI @tianon, thanks a lot for your clarification. @tobias-trabelsi-sonarsource knows much more on the docker topic, but i get your point now. Due to Europe time zone, we will get back to fix it tomorrow morning.

[tobias-trabelsi-sonarsource]

@tianon we are reverting back to set -eux (see PR #468) . can you give any explanation why you think this is a worse implementation? i would value them as equal if we set -o pipefail to the long && chain and it would greatly reduce the maintenance effort on our side