Ability to add a plugin via URL, that is not in a plugin registry

[tomgeorge]

Is your enhancement related to a problem? Please describe.

In hosted che, we would like to add a set of default plugins without including them in the che-plugin-registry. Instead, we would like to configure che server with a list of URLs to plugin meta.yaml files.

Describe the solution you'd like

We would like to edit the CHE_WORKSPACE_DEVFILE_DEFAULT__EDITOR_PLUGINS environment variable in che server, referencing plugin URLs instead of name/publisher/version coordinates.

Likely the plugin broker and plugin resolution code in Che would need to change.

Describe alternatives you've considered

Additional context

This would enable redhat-developer/rh-che#1750

[ibuziuk]

@amisevsk do you see any impediments for having this in place on the plugin-broker end ?

[amisevsk]

The plugin broker always takes in plugin FQNs -- the value in CHE_WORKSPACE_DEVFILE_DEFAULT__EDITOR_PLUGINS is parsed in DefaultEditorProvisioner to a map, e.g.:

{
  "eclipse/che-machine-exec": "eclipse/che-machine-exec/7.7.0",
}

As a result, there are no issues on the plugin broker side implementing this, provided the plugins are parsed correctly.

However, on the Che side, we depend on being able to discover the publisher/name for each default plugin, so that they can be overridden. For example, if your workspace defines eclipse/che-machine-exec/7.6.0 and the default is 7.7.0, we need to be able to match eclipse/che-machine-exec to avoid provisioning both 7.6.0 and 7.7.0 -- it's not clear how this would work when the plugin is defined as a URL reference. If that problem is solved, then it should be dead simple to get provisioning to work, as the same machinery for turning

components:
  - type: chePlugin
    reference: https://my-url.io

into a plugin FQN is already used.

[amisevsk]

Something like master...amisevsk:default-plugin-reference should be sufficient to do this, though I haven't tested it.

[ibuziuk]

PR #15757 merged. Closing