Consideration of a plugin registry / app store for future optional plugins

[phantomjinx]

With the possibility for plugins that could be included on an optional basis, consideration should be given to the necessity and technical feasibility of a hosted plugin registry that could act as a source for installable / downloadable plugin packages.

A process would be required in the hawtio applications that allows:

• connection to a hosted plugin registry, allowing browsing of the avaiable packages;
• selection, download and installation of a plugin package;
• refreshing of the live application to allow for the reloading of the application complete with the new plugin.

The API for these requirements would be necessary in this repository as well as the UI, using the preferences UI as a template for this design.

[tadayosi]

This is a highly valuable suggestion.

One thing I would like to clarify is that Hawtio plugins are already available as Maven artifact JARs or NPM packages. This means we can already utilise Maven Central, NPM registries, or GitHub repositories as registries. Therefore, the "Plugin Store" feature discussed here should be designed to leverage these existing infrastructures rather than building a new mechanism from scratch.

As we move forward with the design of the public registry/catalog/store, I believe JBang’s catalog and app store mechanisms would be a great reference.

Catalog:
https://www.jbang.dev/documentation/jbang/latest/alias_catalogs.html

App Store:
https://www.jbang.dev/appstore/

[grgrzybek]

Interesting!
I'm too narrow minded and low-level focused to provide any valuable "big picture" feedback...

From the low-level point of view, the "API" should be using/reusing/similar to what we already have for dynamic plugins - Module Federation. After I read everything I could about it, it's still a bit confusing, but we have two approaches to MF:

• with Webpack MF plugin - it's kind of static loading of MF modules (actually JS modules with a tiny metadata) to be staticly bundled with the webpack output
• with @module-federation/utilities - this is how Hawtio loads JS modules discovered first with /plugin endpoint. And this /plugin endpoint (returns a JSON array of MF metadata) is again a bit static.

So to be 1) fully dynamic, 2) independent on JMX discovery of plugins at Java/Server side, we simply have to replace /plugin endpoint with something less Java-specific.

I think we can do it ;)