Claus Ibsen created CAMEL-24564:
-----------------------------------
Summary: camel-console: Generate a static OpenAPI spec for all dev
consoles and publish it in the camel-catalog
Key: CAMEL-24564
URL: https://issues.apache.org/jira/browse/CAMEL-24564
Project: Camel
Issue Type: New Feature
Components: camel-core
Reporter: Claus Ibsen
ApiDevConsole (core/camel-console) already generates an OpenAPI 3.0 spec for
the /q/dev/* dev console endpoints, but only live, from a running CamelContext
(CAMEL-24514, https://github.com/apache/camel/pull/25883).
CAMEL-24514 added a "readOnly" flag to the @DevConsole annotation and to each
console's generated catalog metadata
(src/generated/resources/META-INF/org/apache/camel/dev-console/<id>.json)
specifically so this classification (GET vs POST) is available statically at
build time, not just at runtime.
This ticket is to build on that: add a build-time/tooling step (likely in
tooling/camel-package-maven-plugin and/or the catalog module) that aggregates
the per-module dev-console/*.json catalog metadata across the whole build into
one consolidated static OpenAPI document (e.g. openapi.json), and publish it as
part of the camel-catalog, so tools can discover the dev console API surface
(paths, verbs, parameters) ahead of time without needing a running CamelContext
instance.
Suggested approach:
- Reuse the path/operation-building logic already in
ApiDevConsole.buildOpenApi() (or extract it into a shared helper) so the static
generator and the live /q/dev/api console stay consistent.
- Aggregate across all catalog/*.json + component dev-console/*.json resources
at catalog-build time (similar to how other catalog artifacts such as
components.properties / data formats are aggregated today).
- Store the generated spec in catalog/camel-catalog (or a dedicated location)
and expose it via CamelCatalog similar to other catalog lookups.
Related: CAMEL-24514 / PR #25883 (readOnly metadata), and PR #25884 (chore:
removed an unrelated stale dev-console catalog entry found while regenerating
metadata for this work).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)