oscerd opened a new pull request, #3083: URL: https://github.com/apache/camel-kamelets/pull/3083
Covers **part A only** of #328 — the convention — and deliberately not the rest. It does not close the issue. ## Why this is worth doing at all #328 and #929 were both argued on the premise that the declaration "hangs off `dataTypes`, so a Kamelet that does no data type transformation has no natural place to put it". I wrote that myself on #328. **It is wrong**, and since it was the stated blocker on both issues, it is worth correcting in the developer guide rather than just in a comment. A `headers` block is valid on its own, with no `types` and no `default`. Verified three ways rather than assumed: **1. Runtime.** Added `dataTypes.in.headers` to `log-sink`, which has no `dataTypes` block at all, and ran it on Camel 4.22.0: ``` Apache Camel 4.22.0 (probe) started in 275ms log-sink : Exchange[ExchangePattern: InOnly, BodyType: String, Body: hello] ``` **2. Catalog.** `KameletsCatalog.getDeclaredHeaders` iterates the `dataTypes` values and reads `getHeaders()` without requiring `types`, so the declaration is what `getKameletSupportedHeaders` answers with — the behaviour #3061 and #3075 established. **3. Build.** Added the same shape to `aws-kinesis-source` and ran a full root build: `CatalogValidator` accepts it, and the `library/camel-kamelets` resource copy propagates it. Reverted afterwards — this PR touches only `development.adoc`. Worth a reviewer knowing: **no Kamelet in the catalog currently uses this shape.** All 17 that declare side-level headers also have a `types` block, because they all transform. So this documents a valid-but-unused shape, which is exactly the point — it is what a non-transforming Kamelet needs. ## What the section says A new `=== Declaring headers without a transformation` at the end of "Kamelet data types": the shape, which side to use (`out` for a source, `in` for a sink or action), and two reasons it earns its lines — * the component fallback answers a different question (everything the component *can* emit), so it over-reports headers a template never surfaces and misses the ones the template sets itself; * because that fallback follows the component, the catalog's header test tracks upstream Camel for every Kamelet that declares nothing. It also states the precedence #3075 settled: where a side declares both a top-level `headers` block and headers inside its `types`, the top-level block wins, since those are present whichever data type is in use. ## Scope Documentation only — one file, no Kamelet, schema or code change. Still open on #328 and **not** addressed here: - **B, validator enforcement.** A rule flagging a Kamelet that declares nothing for its own side would fire on 243 of 262, so it has to start as a warning. That is a judgement call about whether a warning hitting 93% of the catalog is useful pressure or noise, and I would rather it were made explicitly than arrive attached to a docs PR. - **C, backfilling** the 87 component-derived test assertions, best done opportunistically as Kamelets are touched. - **D, payload examples** (point 3 of the issue), which genuinely has no mechanism and needs a schema conversation. --- _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]
