bamaer opened a new issue, #8403:
URL: https://github.com/apache/hop/issues/8403
### What would you like to happen?
### Background
There is currently no supported way to get a machine-readable inventory of
what a
given Hop installation actually contains. Tooling that needs this today
resorts to
parsing Hop's Java source, which has three problems: it goes stale against
the
running version, it cannot see third-party or Marketplace plugins installed
at a
site, and it yields unresolved `i18n::` keys instead of real labels.
The information already exists in `PluginRegistry` at runtime. It just isn't
reachable from a pipeline.
### Proposal
A `PluginCatalog` source transform that reads the live `PluginRegistry` and
emits
one row per plugin, with options to include transforms, actions and metadata
types.
For each plugin it reflects over the metadata class to expose its
`@HopMetadataProperty` fields, descending one level into complex property
groups.
Output fields: `plugin_id`, `plugin_type`, `name`, `description`, `category`,
`keywords`, `class_name`.
Two detail levels:
- `PER_PLUGIN` — one row per plugin, properties as a JSON array column
- `PER_PROPERTY` — one row per property (`property_field`,
`property_xml_key`,
`property_java_type`, `property_password`, `property_group`), plugin
columns repeated
Because it reads the registry rather than source, labels come back resolved
and
third-party plugins are included automatically.
### Use cases
- **AI assistants.** The AI Advisor SPI added in #8330 anticipates exactly
this:
`IAiAdvisor.listInclusions()` notes that "a plugin-id catalog may default
on so
proposals can use real ids." Advisor proposal quality depends on the model
knowing
real plugin ids and real property keys; a registry-derived catalog
supplies both,
including for plugins the advisor's authors never saw.
- **Documentation generation** — verify manual coverage against what
actually ships.
- **Auditing** — report which plugins are installed across environments.
- **Migration and refactoring tooling** — resolve property names without
guessing.
### Implementation notes
- Property extraction is a pure static method, unit-tested against fixture
classes
with no registry bootstrap required.
- Nesting is capped at one level, matching how tabular property groups are
modelled
elsewhere.
- The `@HopMetadataProperty(password = true)` flag is carried through so
consumers
can redact.
- Plugins whose metadata class fails to load are reported through a warnings
sink
rather than failing the pipeline.
- Labels are locale-resolved by the registry; English search aliases are
emitted
alongside them so generated artifacts stay locale-independent.
### Issue Priority
Priority: 2
### Issue Component
Component: Transforms
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
