Claus Ibsen created CAMEL-26245:
-----------------------------------
Summary: camel-api-component-maven-plugin - the catalog method
signatures show the argument names before substitution, so inBody with the
shown name fails with No matching method
Key: CAMEL-26245
URL: https://issues.apache.org/jira/browse/CAMEL-26245
Project: Camel
Issue Type: Bug
Components: tooling
Reporter: Claus Ibsen
Fix For: 4.24.0
Found while adding the catalog body types of google-calendar, google-drive,
google-mail and google-sheets (CAMEL-24961, PR #28403).
h4. 1. The catalog signatures name the argument content, but the endpoint
expects the substituted name
The google-calendar, google-drive, google-mail and google-sheets {{pom.xml}}
rename the {{content}} argument with {{<substitution>}} (for example
{{content}} of type {{ModifyMessageRequest}} becomes {{modifyMessageRequest}},
google-mail {{pom.xml}} lines 240-245), and the generated {{*ApiMethod}} enums
use the new name ({{GmailUsersMessagesApiMethod}} line 108:
{{arg("modifyMessageRequest", ...)}}). The signatures written into the catalog
and the {{@ApiMethod(signatures = ...)}} still carry the original names
({{modify(String userId, String id, ModifyMessageRequest content)}}):
{{AbstractApiMethodGeneratorMojo}} (main 2a465aa4814c, lines 112 and 592-597)
stores {{model.getSignature()}} as it was parsed. A user who follows the
catalog and sets {{inBody=content}} gets "No matching method" at endpoint
creation. Seen with modifyMessageRequest, values, file,
batchUpdateSpreadsheetRequest and others. Checked on 4.24.0-SNAPSHOT with a
fake {{MockHttpTransport}} client. camel-braintree and camel-zendesk also use
substitutions (not checked).
Proposed: apply the substitutions to the argument names of the signatures
written to the catalog and the {{@ApiMethod}} annotations.
_Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
