Add Camel WSDl2Rest VS Code Extension (#120) - revision

[bfitzpat]

Signed-off-by: Brian Fitzpatrick [email protected]

create Pull request to check if tests are passing.

What does this PR do?

• this PR is adding the Camel WSDL2Rest extension to the list of extensions in Che
• also adds new plugin to the v2 folder
• also updates meta.yaml formatting for v2

What doesn't this PR do?

• add v3 support. I attempted to figure out what needed to be added to the v3 yaml and got lost quickly.

[bfitzpat]

Attempted to figure out what to do with the v3 changes to the yaml file, but have no idea how to fill out the spec portion.

[bfitzpat]

Plus we still have the eclipse-che/che#13232 issue to resolve.

[garagatyi]

@bfitzpat we will move to v3 quite soon. Could you also add this plugin to v3 folder (with adaptation to meta.yaml structure that v3 uses). You can take a look at other plugin to see how meta.yaml looks in v3

[garagatyi]

If you don't add your plugin to v3 this won't break this PR actually. You would be able to successfully merge it. But when we move Che to usage of registry v3 plugin will be absent.

[bfitzpat]

If you don't add your plugin to v3 this won't break this PR actually. You would be able to successfully merge it. But when we move Che to usage of registry v3 plugin will be absent.

I will see about getting this done today. Thanks

[bfitzpat]

@garagatyi - Looks like I have added the v3 bits correctly.

[garagatyi]

Looks good!

[bfitzpat]

Now that eclipse-che/che#13232 is no longer an issue, can we merge this? I tested it on a che.openshift.io instance and it worked great today.

[bfitzpat]

https://raw.githubusercontent.com/bfitzpat/che-plugin-registry/120-AddVSCodeWSDl2RestVSCodeExtension/v3/plugins/camel-tooling/vscode-wsdl2rest/latest worked great!

[bfitzpat]

Updated PR to point to latest vsix build at new location for Red Hat published artifacts

[apupier]

• folders needs to be updated from camel-tooling to redhat
• extension ids needs to be updated from camel-tooling.vscode-wsdl2rest to redhat.vscode-wsdl2rest

[bfitzpat]

* folders needs to be updated from camel-tooling to redhat

* extension ids needs to be updated from camel-tooling.vscode-wsdl2rest to redhat.vscode-wsdl2rest

Fixed @apupier

[l0rd]

@apupier @bfitzpat we are on stabilisation period and merge only PRs that fix some endgame issue.

[bfitzpat]

@apupier @bfitzpat we are on stabilisation period and merge only PRs that fix some endgame issue.

Yes, we're just getting ready for when [endgame] is done and things open up again. Thanks!

[apupier]

for information, ahead of time. This PR will conflict with this one #196

[amisevsk]

As others have mentioned, the v1 and v2 plugin metas should maybe not be included in this PR, as I believe only beta and rc releases of Che use these paths and they will be removed in the (near) future.

[amisevsk]

Is this a minimum requirement for memory? With a requirement of 1000Mi, running a workspace with this plugin and the Java LS will already consume over 3Gi.

From an OSIO perspective, it would be great if this default limit could be lowered.

[bfitzpat]

Other than thru trial and error is there a way for us to determine how much memory is actually needed @amisevsk ? Or do we even need that container? I was just going by what was being done by other extensions

[amisevsk]

@bfitzpat trial and error is thus far the best approach I've found; I usually open a terminal and monitor memory usage while trying to tax the plugin (e.g. for Java LS, view mem usage while its importing the project). From there I adjust up a little.

As for whether the container is needed, I would ask one of our theia/plugin devs. I can't confidently say one way or another. Some plugins don't require sidecars, e.g. the github pull request plugin.

[bfitzpat]

@amisevsk I have removed the v1 and v2 versions of the metadata for this extension/plugin. And I tested in che.openshift.io with the smaller memory footprint (256Mi) -- seems to work fine. Please let me know if you need anything else

[amisevsk]

LGTM, thanks. One concern is that including this plugin in the current apache-camel devfile will be difficult due to memory quotas on osio, but that's a separate issue.

[amisevsk]

@l0rd Should this PR be merged for 7.0.0?

@apupier I believe the changes you requested have been implemented.

[apupier]

@apupier I believe the changes you requested have been implemented.

yes

[l0rd]

@apupier @amisevsk che 7.0.0 has been released and we can proceed with the merge of this PR if you are ready

[apupier]

I plan to have a look at it at the beginning of September.

[apupier]

I wasn't able to manage to change the registry locally but I was able to point to the files directly from a workspace configuration to test it on a 7.1.0-SNAPSHOT Che version

components:
  - id: >-
      https://raw.githubusercontent.com/bfitzpat/che-plugin-registry/120-AddVSCodeWSDl2RestVSCodeExtension/v3/plugins/redhat/vscode-wsdl2rest/latest/meta.yaml
    memoryLimit: 128Mi
    type: chePlugin

it works fine.

[apupier]

can one of the Code Owner review it too so that I can merge it? @l0rd @rhopp @skabashnyuk @vparfonov