* Add component type filter for extensionPoints
* Bump js-extensions beta version
* EXTENSIONS -> README
* more documentation for dataType vs. componentType
* modify usage of 'type' to 'dataType' for consistency
* Split ClassMetadataStore, modify extension filtering to a common method
* Separate componentType to its own file
* Redux skeleton code for testResults
* Render the test suites on the test tab
* JENKINS-35990 - Refactoring JS extensions API
* Refactor ExtensionStore and related to ES6 classes, add tests and docs
* Bump js-extensions versions
js-builder now looks for "extDependencies" in the "jenkinscd" section of the package.json and generates
adjunct js-module bundles for the dependencies specified in their. js-modules triggers async loading from
the same adjunct urls.
This all means that we no longer need to create HPIs for these bundles (or most of them anyway - can still
if we need to). Instead, each plugin will bundle its own dependencies. At runtime, if that dependency
has not already been loaded by another plugin, js-modules will trigger loading of the dep from the adjunct url.
js-builder generates the dep bundle such that it ends up being bundled in the HPI. So, multiple plugins may end up
having the same js bundles (generated by js-builder), but that's ok as we include the version number in the URL.
At the moment, we blank out the patch version, which means we always treat e.g. v3.2.1 as being compatible with
v3.2.9, but do not treat v3.2.1 and v3.3.1 as being compatible. Hope this makes sense.
Blue Ocean core will be able to create and "export" this (js-modules export). Plugins will "import" that shared instance, allowing them to register/add extension points etc etc.
Will need to enhance the render function to do the async loading of modules when it encounters extension points that are not yet registered.
Cliff Meyers
tfennelly
Keith Zantow
Thorsten Scherler
Josh McDonald