This folder contains projects which help working with and extending the UI:
module-api
: pattern for UI projects to advertise themselves as UI modulesmodule-registry
: track installed UI modules and serve them at /ui-module-registry
external-modules
: enricher to allow entities to install new modulesmetadata-registry
: supply miscellaneous server-supplied data at /ui-metadata-registry
proxy
: simple proxy serverfeature
: builds this as an OSGi featureNote that UI modules themselves are in ../ui-modules
.
A Brooklyn UI module is a WAR being installed which includes a file ui-module/config.yaml
defining at minimum:
name
(to be displayed in the UI)slug
(used internally for reference; usually this is set to be ${project.artifactId}
and substituted during the build)icon
CSS class set, usually Font Awesome based (e.g. fa-home
).Optionally it can include:
type
tokens for arbitrary use (currently home-ui-module
is used to indicate a module should show up on the home page, and library-ui-module
to indicate it should be excluded from the menu)actions
(not used currently, see code to understand)stopExisting
(boolean, whether to stop lower-numbered bundles listening on the same context-path declared in web.xml
, defaulting to true
)supersedes
(a list of bundle-regex:version-regex
of bundles that should be stopped when this UI module is installed; this is used for downstream projects that may override UI modules and wish to ensure their modules are used without relying on bundle install order (but often bundle install order is sufficient))The Karaf command web:list
is helpful in determining which module is actually active when there are conflicts for a given context path.