JiriOndrusek opened a new issue, #9152: URL: https://github.com/apache/camel-quarkus/issues/9152
#9142 delegates the extension's engine to the `camel-langchain4j-ingest` component, while the route topology stays in Camel Quarkus as a package-private pipeline assembly (`IngestPipelineDefinition`, `IngestPipelineRouteBuilder`) — explicitly documented as a temporary internal copy. apache/camel-kamelets#3016 (fixing apache/camel-kamelets#3015) introduces the declarative twin of that topology: `langchain4j-ingest-sink`, `langchain4j-ingest-file-source` and the generic `tika-extract-text-action` / `docling-convert-action` Kamelets. Once a camel-kamelets release ships them, the extension should compose its pipelines from those Kamelets instead of generating the routes in Java: - directory pipelines: `file-source` Kamelet → (parser action when `parser` is set) → `sink` Kamelet; consumer pipelines: `from(uri)` → (action) → `sink` - delete `IngestPipelineDefinition` / `IngestPipelineRouteBuilder`; `IngestRoutes` becomes a thin translator from the existing configuration/`@Ingest` surface to Kamelet parameters - add `camel-kamelets` (catalog), `camel-quarkus-kamelet` and `camel-quarkus-yaml-dsl` dependencies Behaviour-neutral by design: no configuration, API or semantics change — the existing integration tests must pass unmodified. The win is a single topology source of truth shared across Camel runtimes. Gated on: #9142 merged, and a camel-kamelets release (4.23.x) containing the ingestion Kamelets. _Claude Code on behalf of @JiriOndrusek_ -- 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]
