oscerd commented on issue #328: URL: https://github.com/apache/camel-kamelets/issues/328#issuecomment-5979118553
Took part A: #3083 documents the convention in `development.adoc`. It references this issue without closing it — B, C and D are untouched. Before writing it I verified the shape three ways rather than relying on the reader code alone, since I was documenting something no Kamelet currently uses: | | result | |---|---| | runtime (`camel run`, `log-sink` + `dataTypes.in.headers`, Camel 4.22.0) | starts, processes a message | | catalog (`getDeclaredHeaders`) | reads it — iterates `dataTypes` values, no `types` required | | full root build (`aws-kinesis-source` + `dataTypes.out.headers`) | `CatalogValidator` accepts it; the `library/camel-kamelets` copy propagates it | Both probes reverted; the PR touches only `development.adoc`. One thing worth stating plainly for anyone reading this later: **all 17 Kamelets that declare side-level headers today also have a `types` block**, because they all transform something. So the documented shape is valid but unused — which is the point, since it is what the other 243 need. **B is still yours to call and I have not pre-empted it.** A validator rule flagging a Kamelet that declares nothing for its own side would fire on 243 of 262 on day one, so it can only start as a warning. Whether a warning at that hit rate is useful pressure or just noise is a taste question about this catalog, and I would rather it were decided on its own than arrive bundled with a docs change. Same for C (opportunistic backfill of the 87 component-derived assertions) and D (payload examples, which needs a schema addition). --- _Claude Code on behalf of Andrea Cosentino_ -- 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]
