davsclaus opened a new pull request, #28437: URL: https://github.com/apache/camel/pull/28437
JIRA: https://issues.apache.org/jira/browse/CAMEL-25928 **Stacked on #28436** (which is stacked on #28435 and #28424): this PR targets its branch. ## What **One rule to read a body type, in the tooling model.** `BodyTypeResolver` (camel-tooling-model) reads one side of the body types for the options a step sets: 1. An option the side names that is a placeholder or an expression, or that the step does not set but the component could: not known. 2. An option in `dependsOn` that the step sets: the `byOption` entry for that value decides; without one, not known. 3. Otherwise, the `javaTypeOption` the step sets: an object of that class, or null. 4. Otherwise, the `byOption` entries for the values the step sets; when two disagree, not known. 5. Otherwise, the carriers; `unknown` is not known. It also compares option values in any case and in any style of an enum constant (`isSameValue`). - The YAML validator's `CatalogBodyTypes` now calls it instead of its own copy. - The package plugin's build check uses its `isSameValue`. So the tools, the docs and any other reader of the catalog follow the same rule. The plan's next step (the validator reads the body types of EIPs and languages) builds on it. **A new user manual page: Message Body Types** (`body-types.adoc`, in the Architecture section of the nav, *Available as of Camel 4.24*): - **What the body types are and how they help:** routes that cannot work are found before they run, the doc pages say what each step gives, AI assistants write steps that fit, and you see what the bodies were at runtime. - **Carriers and sides:** tables of the carriers (with the kinds the runtime records) and of the sides. - **Examples:** - a route the validator reports, and its fix; - options that change the body (xslt `output`); - options that name the class (`resultType`, sql `outputClass`); - EIPs (`from`, `split`). - **Tooling:** the doc pages, `camel catalog doc` and MCP, the YAML validator, and the runtime (message history, dev console, JMX, the Camel CLI diagnostics, diagram and source editor, the report plugin). - **Declaring body types:** `@BodyTypes` and the checks of the build. - **Reference for tools and AIs:** the fields of a side, the rule to read a side for a step, the carrier of a class, and the Java API. `camel-catalog.adoc` keeps a short section with a link to the page. The links of the MCP, validation and endpoint annotation pages, and the Message Body section of the component pages, now point to it. ## Tests - **camel-tooling-model:** `BodyTypeResolverTest` covers each step of the rule, a `byOption` with a `javaTypeOption`, two values that disagree, and enum values in any style. - **Validator and package plugin:** their tests pass unchanged (295 and 115). - **The page's YAML examples:** - they pass `UserManualDocExamplesTest`; - the route that is wrong on purpose has the skip marker; - its validator message, as the page quotes it, is the one the validator gives. - **Local full check:** the catalog, the validator and camel-jbang-core. _Claude Code on behalf of davsclaus_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_0128ThHB3iQdrvSRLVBGRrdP -- 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]
