Split @hawtio/react package into core and plugins

[tadayosi]

There is a request from Artemis dev team (the main consumer of the plugin API) to expose key objects such as workspace and treeProcessorRegistry from @hawtio/react's src/plugins.

While we can just carelessly export everything in src/plugins from src/index.ts (like below) so that users can consume them from @hawtio/react, I don't think it's a good design because we cannot provide a clear separation between the core and plugins.

export * from './plugins`

To achieve the goal of providing the resources from the plugins to users while keeping a clear separation between core and plugins, currently I think the only way is to split the @hawtio/react package into two: @hawtio/react (core) and @hawtio/react-plugins (plugins). That means the packages should look like this:

packages/
├── camel-model/
│   └── package.json
├── hawtio/
│   └── package.json
└── plugins/
    └── package.json

This is getting more to resemble the legacy JS components structure, but since we'll still keep monorepo it shouldn't be of much burden for releasing each package unlike it was with the legacy Hawtio.

What do you think? @phantomjinx @mmelko @joshiraez

[tadayosi]

By the way, this simpler approach tadayosi@e7b36b0 (using tsup multiple entries to separate core and plugins) badly fails because then we have two different cores with the two entries, so the states of the core services are not in sync between entries.
https://github.com/tadayosi/hawtio-next/tree/export-plugins-tsup

[tadayosi]

The PluginNodeSelectionContext introduced a circular dependency between ui/page and plugins, and thus it's not easy to split @hawtio/react into two packages. We need to find an abstraction for the context before splitting it into two.
https://github.com/hawtio/hawtio-next/blob/main/packages/hawtio/src/plugins/selectionNodeContext.ts

[joshiraez]

My thoughts are what you said in the original statement, that like this we are resembling more the base version. And even though we are still monorepo, it might add additional complexities.

Are there any list of requirements they want available?

[tadayosi]

@joshiraez The requirements: https://github.com/apache/activemq-artemis/blob/main/artemis-hawtio/artemis-plugin/src/main/webapp/plugin/js/artemisPlugin.js
I think every internal API we use to implement Camel plugin should be also provided to external plugin developers. It's us who need to define the API.

[joshiraez]

Definitely. I'll take a look at that and try to bring more feedback

[tadayosi]

I haven't yet decided whether we should merge this pull req #232 now. #232 revealed that these are the API that are needed to implement Camel plugin externally.

AttributeValues
Attributes
Chart
EVENT_REFRESH
HawtioPlugin
JmxContentMBeans
Logger
MBeanNode
MBeanTree
Operations
PluginNodeSelectionContext
PluginTreeViewToolbar
TreeProcessor
configManager
eventService
hawtio
jolokiaService
workspace

At this moment, it may be sufficent to just export these from @hawtio/react for external plugin development.