Plugin Catalog
DescriptionThe Plugin Catalog transform reads the live Hop plugin registry and emits one row per installed plugin: transforms, workflow actions and metadata types. For each plugin it also reflects over the plugin’s metadata class and reports the Because the catalog comes from the registry of the running Hop installation rather than from a static list, it always matches the version in use and includes any third-party or Marketplace plugins that are installed. This is a source transform: it generates rows and does not read an input stream. |
Supported Engines
|
Usage
The catalog answers questions about what a given Hop installation actually contains, for example:
-
generating or checking documentation against the plugins that really ship
-
auditing which plugins are installed across environments
-
supplying an AI assistant with real plugin ids and property names instead of guessed ones
-
building migration or refactoring tooling that needs to resolve property names
Options
| Option | Description |
|---|---|
Transform name |
Name of the transform, unique within the pipeline. |
Include transforms |
Emit an entry for every registered pipeline transform plugin. |
Include actions |
Emit an entry for every registered workflow action plugin. |
Include metadata types |
Emit an entry for every registered Hop metadata type, such as relational database connections or run configurations. |
Detail level |
|
Output fields
Every row carries these plugin-level fields:
| Field | Type | Description |
|---|---|---|
|
String |
Plugin id, for example |
|
String |
|
|
String |
Display name, resolved against the Hop locale in use. |
|
String |
Description, resolved against the Hop locale in use. |
|
String |
Category, resolved against the Hop locale in use. |
|
String |
Comma-separated keywords, resolved against the Hop locale in use. |
|
String |
Fully qualified metadata or implementation class. |
|
String |
Comma-separated English name, category and keyword aliases, independent of the locale in use. |
|
String |
BCP-47 tag of the locale the resolved labels above came from. |
PER_PLUGIN adds one field:
| Field | Type | Description |
|---|---|---|
|
String |
JSON array of |
PER_PROPERTY instead adds one row per property, with:
| Field | Type | Description |
|---|---|---|
|
String |
Java field name on the metadata class. |
|
String |
Key the property is serialised under in |
|
String |
Simple Java type name of the field. |
|
Boolean |
|
|
String |
Name of the containing property group for a nested property, empty for top-level properties. This is nesting, not the serialization wrapper. |
|
String |
The |
A plugin with no properties still produces one row, with the property fields empty.
Notes
name, description, category and keywords are resolved by the plugin registry against the locale Hop is running in. When the output is stored or indexed, use english_aliases for lookups that must not depend on the locale, and locale to record which locale the labels came from.
Property reflection descends one level into complex property groups, which covers the tabular property groups plugins use. Deeper nesting is not reported. Group classes are recognised by carrying @HopMetadataProperty fields, whatever package they are declared in, so third-party and Marketplace plugins are described the same way as the ones shipped with Hop.
Properties marked isExcludedFromSerialization are left out, since they never reach a .hpl or .hwf file.
Plugins whose metadata class cannot be loaded are logged at detailed logging level and skipped rather than failing the pipeline, so a single broken plugin does not stop the catalog.