[java-springboot] Use LTS JDK 17 image

[rm3l]

What does this PR do?:

This updates the container image to registry.access.redhat.com/ubi9/openjdk-17, to keep up with the latest JDK LTS, security-wise.
Also JDK 17 is now a requirement for recent versions of Spring Boot.

Which issue(s) this PR fixes:

—

PR acceptance criteria:

• Contributing guide
  Have you read the devfile registry contributing guide and followed its instructions?
• Test automation
  Does this repository's tests pass with your changes?
• Documentation
  Does any documentation need to be updated with your changes?
• Check Tools Provider
  Have you tested the changes with existing tools, i.e. Odo, Che, Console? (See devfile registry contributing guide on how to test changes)
  Tested with odo.

How to test changes / Special notes to the reviewer:

[openshift-ci]

Hi @rm3l. Thanks for your PR.

I'm waiting for a devfile member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[christoph-jerolimov]

/uncc

[kadel]

Now that we have multi-version support, it might be better to keep the old versions (1.2.0 and 2.0.0) there

[rm3l]

Now that we have multi-version support, it might be better to keep the old versions (1.2.0 and 2.0.0) there

Done. I hesitated to do so in the beginning mainly because of the maintenance overhead, but yes, it makes sense to keep the old versions. The default version of the stack still points to the old 1.2.0, but let me know if you think this should be changed.

[kadel]

The default version of the stack still points to the old 1.2.0, but let me know if you think this should be changed.

I would change it, but this is also a question or @elsony

[kim-tsao]

/ok-to-test

[kim-tsao]

The default version of the stack still points to the old 1.2.0, but let me know if you think this should be changed.

I would change it, but this is also a question or @elsony

I raised this in a meeting and we agreed we need to update our samples to work with parent v2.2 versions (currently they don't so if we change the default they will break). This is the tracking issue: devfile/api#1112

[mohitsuman]

@elsony @kim-tsao can we please get this PR merged? We have customers whose workflow is broken due to the older JDK version. We would need this on priority.

[rm3l]

The default version of the stack still points to the old 1.2.0, but let me know if you think this should be changed.

I would change it, but this is also a question or @elsony

I raised this in a meeting and we agreed we need to update our samples to work with parent v2.2 versions (currently they don't so if we change the default they will break). This is the tracking issue: devfile/api#1112

@kim-tsao @elsony @kadel devfile/api#1112 is mostly about parent Devfiles using v2.2.0 schema. But this PR is mostly about updating the container image.
I think we can update the default to 1.3.0 here (still using Devfile 2.1.0, but with JDK 17), so we are not blocked on devfile/api#1112. And once devfile/api#1112 is merged, we would be able to switch the default to a version using Devfile 2.2.0 (maybe as part of devfile/api#1129). WDYT?

[thepetk]

so we are not blocked on devfile/api#1112

@rm3l

I'm not sure I have the full context for the usage of multiple sample versions for this case.

But, fyi after the implementation of devfile/api#1209 we are able to have multiple versions of samples and add them to extraDevFileEntries.yaml. For this specific stack we have already an opened PR on the springboot sample here: devfile-samples/devfile-sample-java-springboot-basic#33

[rm3l]

so we are not blocked on devfile/api#1112

@rm3l

I'm not sure I have the full context for the usage of multiple sample versions for this case.

I think the initial point was whether to switch the default version of this stack to the latest one here (which would be using Devfile 2.2.0). However, the problem mentioned by Kim is that doing so would break the current samples.

But, fyi after the implementation of devfile/api#1209 we are able to have multiple versions of samples and add them to extraDevFileEntries.yaml. For this specific stack we have already an opened PR on the springboot sample here: devfile-samples/devfile-sample-java-springboot-basic#33

Ok (correct me if I'm wrong), so devfile/api#1209 paved the way to supporting versioned samples, but the actual work of updating extraDevfileEntries.yaml would be done in devfile/api#1112, right?

To move forward with this PR, I'm suggesting we decorrelate it from the work being done on samples, by updating the default version of this stack to the one using Devfile 2.1.0 but with JDK 17. This would keep backward compatibility with the current samples as I guess they would still be working with parent v2.1.0 (only with a different container image).
And the task of updating extraDevFileEntries would be handled separately as part of devfile/api#1112, at which point we could also consider switching the default stack version to a version on Devfile 2.2.0 (scope of devfile/api#1129).

[rm3l]

As agreed with the rest of the team, I'm switching the default version of this stack to 1.3.0 (the one still on Devfile 2.1.0, but with a more recent JDK 17), for backward compatibility with the samples.

Also rebased and force-pushed as the branch was a bit outdated.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kadel, rm3l

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:

• stacks/OWNERS [rm3l]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment