oscerd opened a new pull request, #3061: URL: https://github.com/apache/camel-kamelets/pull/3061
Addresses the half of #929 that needs no change to the Kamelet spec. ## The API never consulted the declaration `getKameletSupportedHeaders` took the Kamelet name, stripped the last segment, mapped that to a Camel component and returned the component's endpoint headers. So a caller asking the catalog **what a Kamelet emits** got **what its component can emit**, which is a different question — and `spec.dataTypes.*.headers`, which exists precisely to answer the first one, was never read. ## How far apart the two answers are | Kamelet | declares | component reports | |---|---|---| | `aws-s3-source` | 4 | 26 | | `azure-storage-blob-source` | 8 | 39 | | `google-storage-source` | 4 | 21 | | `google-mail-source` | 6 | 9 | | `google-sheets-source` | 5 | 6 | | **`azure-storage-datalake-source`** | **26** | **25** | That last row is the interesting one. The declaration is *larger* than the component list, so it carries a header the component does not know about — a template-added one, which is exactly the case #929 was opened for. davsclaus's original example was `ftp-sink` declaring `ce-file`, a header the FTP component has never heard of. ## The change `getKameletSupportedHeaders` returns the declared headers when a Kamelet declares any, and falls back to the component otherwise. **Fifteen Kamelets declare headers today, so the other 247 are unaffected.** Six expectations in `testSupportedHeaders` move to the declared counts. Three further declaring Kamelets — `aws-cloudtrail-source`, `azure-storage-queue-source`, `google-calendar-source` — already agreed with their component and are unchanged, which is a small check on the mapping being sane. A new test states the semantics directly rather than leaving them implied by counts: the four names `aws-s3-source` declares, that the Kamelet's own title travels with the header rather than the component's, and that a Kamelet declaring nothing still falls back. ## What this is not **It does change what the API answers for those fifteen Kamelets**, which is visible to tooling that reads it — `aws-s3-source` going from 26 headers to 4 is a real difference in what a UI would show. I think that is the point rather than a cost: the 22 it stops reporting are headers that Kamelet does not emit. But it is a semantic change to a published API and should be judged as one, so it is easy to reject if you disagree. **It does not touch the spec.** The other half of #929 — whether the declaration should be decoupled from `dataTypes`, so that a Kamelet doing no data-type transformation has somewhere natural to put it — is untouched, and remains the reason adoption sits at 15 of 262. Nothing here makes declaring easier; it only makes declaring *worth doing*, which seemed the necessary first step. The same open question covers #328 for media types, which asks for the identical thing about input and output types and has the identical mechanism sitting unused. `mvn clean install` green: `KameletsCatalogTest` 19/19, validator over 262 Kamelets. --- _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]
