CLOUD-2869 add overrides for building jdk 11 based images

[rcernich]

Signed-off-by: rcernich rcernich@redhat.com

Thanks for submitting your Pull Request!

Please make sure your PR meets the following requirements:

• Pull Request title is properly formatted: [CLOUD-XYA] Subject
• Pull Request contains link to the JIRA issue
• Pull Request contains description of the issue
• Pull Request does not include fixes for issues other than the main ticket
• Attached commits represent units of work and are properly formatted
• You have read and agreed to the Developer Certificate of Origin (DCO) (see CONTRIBUTING.md)
• Every commit contains Signed-off-by: Your Name <yourname@example.com> - use git commit -s

[rcernich]

@goldmann, I need to know what to do wrt branch names, etc. I don't see why we can't have these collocated with each other, in the same branch, similar to what we do with JWS. For now, I created a separate overrides file for JDK 11. To build, you need both product-overrides and rhel7-jdk11-overrides. All the latter overrides does is swap jdk from version 8 to version 11. It also changes the osbs settings, but I'm not sure if this is the best way or not. Lemme know.

[goldmann]

Notes:

• The JDK 11 is in contradiction with the repository name. It just doesn't fit here currently. This needs to be changed, see below for the other note.
• The new image name uses a different naming scheme than the previous image. This is confusing. Not sure what we can do about it. The JDK 8 image should use "8" instead of "18".
• I know that we need to have decision regarding branches and naming, I'm just not there because everything that I can find is either unusable, hard to automate or just requires too much work in the product teams.
• I haven't said that we cannot collocate versions, but this needs to fit in the overall release workflow. With JWS this is different, because the collocated things are subproducts under same version, following the same release cadence. JDK is a bit different, since the releases are not really related to each other. Maybe this is not a problem, maybe it is. We need to decide on the best appraoch and have it written down.

No, I don't have immediate answers all these issues. This is why we need (badly) guidelines before proceeding with this. If JDK 11 is an urgent requirement, I can merge this and we can rework later.

[rcernich]

Hey @goldmann, thanks for the feed back.

• The JDK 11 is in contradiction with the repository name. It just doesn't fit here currently. This needs to be changed, see below for the other note.

Yes. I'm wondering if it makes sense to have the major version in the repository name. Branches would feel more natural. Then there's the way we do this for the SCL based images, e.g. https://github.com/sclorg/s2i-python-container.

• The new image name uses a different naming scheme than the previous image. This is confusing. Not sure what we can do about it. The JDK 8 image should use "8" instead of "18".

Yes, but I think the old name is the problem, not the new name. While the version is 1.8, it's also known as Java 8, so...

• I know that we need to have decision regarding branches and naming, I'm just not there because everything that I can find is either unusable, hard to automate or just requires too much work in the product teams.

I'm not sure what the scl guys are doing, but they seem to have a single repo for multiple versions. That said, using cekit seems to be much easier than using git modules for common source. They also don't seem to have a problem with using non-rpm content.

As far as building goes, should we start including jenkins files in our source?

• I haven't said that we cannot collocate versions, but this needs to fit in the overall release workflow. With JWS this is different, because the collocated things are subproducts under same version, following the same release cadence. JDK is a bit different, since the releases are not really related to each other. Maybe this is not a problem, maybe it is. We need to decide on the best appraoch and have it written down.

Having a repository for each version is not the right solution IMO. This really complicates the development process and makes it hard for users to locate the "correct" repository. Having a single "Java" source repo makes for one-stop shopping. Whether the different versions are in different branches or different subdirectories, it's all in one place. Longer term, it would also be nice if the Java specific modules were located here too (real one-stop shopping).