Add devfile for the Vert.x Java Stack with runtime ubi8/openjdk-11 image

[RomanNikitenko]

What does this PR do?:

At the moment quay.io/eclipse/che-java11-maven:7.37.2 is used as a runtime image for the Vert.x Java Stack.
The image was not updated about 2 years: https://quay.io/repository/eclipse/che-java11-maven?tab=tags.
Also, it's not possible to start Che-Code using that image - starting a workspace fails with the error: /checode/checode-linux-libc/node: error while loading shared libraries: libbrotlidec.so.1: cannot open shared object file: No such file or directory.

I propose to add a new version of the devfile with the runtime image registry.access.redhat.com/ubi8/openjdk-11:1.18-2.

Which issue(s) this PR fixes:

eclipse-che/che#22785
eclipse-che/che#22525

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)

How to test changes / Special notes to the reviewer:

[openshift-ci]

Hi @RomanNikitenko. 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.

[thepetk]

I think a better approach could be here to create a new version of the vert.x stack. We can take as an example the java-wildfly stack. WDYT?

[thepetk]

/ok-to-test

[michael-valdron]

I think a better approach could be here to create a new version of the vert.x stack. We can take as an example the java-wildfly stack. WDYT?

+1

[RomanNikitenko]

I think a better approach could be here to create a new version of the vert.x stack. We can take as an example the java-wildfly stack. WDYT?

thank you for the quick feedback!

I'm going to provide the corresponding changes, but first I would like to confirm that I understand correctly what I should to do:

• create folder 1.2.0 and move the current devfile without my changes to that folder (it has 1.2.0 version)
• create folder 1.3.0 and place the devfile with my changes in that folder?
• provide stack.yaml, 1.3.0 is default?

thanks in advance!

[michael-valdron]

I'm going to provide the corresponding changes, but first I would like to confirm that I understand correctly what I should to do:

• create folder 1.2.0 and move the current devfile without my changes to that folder (it has 1.2.0 version)
• create folder 1.3.0 and place the devfile with my changes in that folder?
• provide stack.yaml, 1.3.0 is default?

@RomanNikitenko These are the correct changes 👍

Additionally, with the versions defined in their devfiles as 1.2.0 version currently does.

[thepetk]

I think a better approach could be here to create a new version of the vert.x stack. We can take as an example the java-wildfly stack. WDYT?

thank you for the quick feedback!

I'm going to provide the corresponding changes, but first I would like to confirm that I understand correctly what I should to do:

• create folder 1.2.0 and move the current devfile without my changes to that folder (it has 1.2.0 version)
• create folder 1.3.0 and place the devfile with my changes in that folder?
• provide stack.yaml, 1.3.0 is default?

thanks in advance!

Yes I think this is correct!

[michael-valdron]

One correction needed:

- stacks/java-vertx/1.3..0/devfile.yaml
+ stacks/java-vertx/1.3.0/devfile.yaml

[thepetk]

Other than @michael-valdron comment above looks good to me

/lgtm

[michael-valdron]

/lgtm

[ibuziuk]

@thepetk @michael-valdron folks, could you please clarify who can provide guidance regarding the odo v3 failing PR check?

[RomanNikitenko]

I've changed default version for the Vert.x Java stack.
Maybe 1.3.0 should be used here

[michael-valdron]

@thepetk @michael-valdron folks, could you please clarify who can provide guidance regarding the odo v3 failing PR check?

I've changed default version for the Vert.x Java stack.
Maybe 1.3.0 should be used here

@RomanNikitenko is right, we skip vertx stack starter projects in the odo checks because they exceed the resource limit of GitHub workflows, following are some past related PRs:

• Add odo v3 tests and break validation tests into separate jobs #132
• Add vertx-secured-http-example in odov3 skipped starterprojects #264
• Add vertx-configmap-example to odo3 check's skipped starterprojects #280

[michael-valdron]

We'll need to keep both versions here, mainly so that this PR can pass since 1.2.0 was refactored in these changes.

[michael-valdron]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ibuziuk, michael-valdron, RomanNikitenko, thepetk

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:

• OWNERS [michael-valdron,thepetk]

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

[RomanNikitenko]

thank you all for your support and guidance to get the PR merged!