[Dhairya-007]

Running codespell over the generated catalog (the text that ends up on the component pages, in the catalog tooling and in the DSL javadoc) finds 18 real misspellings in option and header descriptions. This PR fixes each one at the source the generator reads (the @UriParam/@Metadata literal or the setter javadoc) and propagates it by hand to every generated copy: the component JSON, the camel-catalog copy (asserted byte-identical), the component DSL factory and the endpoint DSL factory. The DSL javadoc is re-wrapped with EndpointDslMojo.formatJavadocOrCommentStringAsList's algorithm, verified by first reproducing the existing blocks byte-for-byte, so a regen should produce no diff; if CI's regen disagrees I will take its patch.

Misspelling	Where
entrys	atom idempotentStrategy
everytime	chatscript resetChat, IOHelper javadoc
statics → statistics	controlbus action, the controlbus and stream-caching docs, InternalProcessor/CamelInternalProcessor javadoc
Certficates	crypto keystore, keyStoreParameters
registy	cxfrs providers
cpoy	google-mail-stream CamelGoogleMailStreamBcc header
transfered	hazelcast-seda transferExchange
Address ot / path ot	jgroups-raft CamelJGroupsRaftLeaderAddress header, knative environmentPath
proccess	jira verificationCode
$metdata	olingo2/olingo4 edm API parameter (javadoc of Olingo2App/Olingo4App, which the API component plugin copies)
seperated	robotframework metadata
retrive	salesforce refreshToken
interprete	solr deleteByQuery
custum, implementaion	weather geoLocationProvider
withing	web3j position option and CamelWeb3jPosition header, Budget javadoc
one ore more	camel-main autoConfigurationFailFast and useDataType (both configuration-properties classes, the generated metadata and its catalog copy, main.adoc), RemoveHeadersProcessor/RemovePropertiesProcessor/CamelContextFactoryBean javadoc

The two edited .adoc files (controlbus-component.adoc, main.adoc) are mirrored into catalog/camel-catalog/.../docs/, which were byte-identical before the change.

Left alone on purpose, so this is not a blind codespell run:

• retainUncommitedData (azure-storage-datalake) is an option name; renaming it would break users.
• ${substring(1,-1)} -> ello Worl in the simple language is the example's intended output.
• useable is an accepted spelling.
• Debezium descriptions are generated from Debezium's own configuration definitions.

Doc-only change, no behaviour change.

[gnodet-bot]

These fixes only patch the generated copies — the upstream @UriParam / @Metadata source strings are unchanged. A routine mvn generate-sources will revert everything.

Missing source file — atom (idempotentStrategy):
AtomEndpoint.java, line 56 still reads:

+ "The default strategy checks the Atom entrys updated or published date is newer than the previously read entry. "

That string is never touched by this PR; the JSON copy was edited directly.

The same pattern applies to the other three components (chatscript, controlbus, crypto): the @UriParam or @Metadata description literal in the actual Java source file must be fixed first; the generated files should then be regenerated (or updated consistently if the project commits them by hand, which requires documenting that convention).

Incomplete — 13 of 17 components missing:
The PR description lists 17 components but the diff covers only 4: atom, chatscript, controlbus, crypto. The other 13 (cxfrs, google-mail-stream, hazelcast-seda, jgroups-raft, jira, knative, olingo2, olingo4, robotframework, salesforce, solr, weather, web3j) plus the camel-main / IOHelper / InternalProcessor / Budget / RemoveHeadersProcessor javadoc changes are entirely absent from the diff.

Suggested correction — entrys → entry's (not entries):
The original sentence was: "checks the Atom entrys updated or published date is newer than the previously read entry."
entrys is a misspelling of the possessive entry's — the strategy checks one entry's date at a time. entries (bare plural) is grammatically weaker; entry's matches both the singular subject and the surrounding context (note the closing phrase "the previously read entry"). Worth fixing correctly at the source.

This review was generated by an AI agent, Hermès on behalf of @gnodet.

[davsclaus]

Thanks for this. The four spellings that are in the diff are correct ("entries", "every time", "statistics", "Certificates"). But the pushed commit doesn't match the description. It has 12 files, all generated, for 4 of the 17 components, and none of the sources the generator reads:

• No source files changed. AtomEndpoint.java:56 still has "entrys", ChatScriptEndpoint.java:65 "everytime", ControlBusEndpoint.java:144 "statics", and DigitalSignatureConfiguration.java:302/312/359 "Certficates". The build regenerates the JSON and DSL files from these sources, so it will revert every edit here and CI will fail on uncommitted changes.
• The crypto fix is also missing from DigitalSignatureEndpointBuilderFactory (lines 98, 117, 426 and 447 still say "Certficates"), even though the endpoint-level keystore/keyStoreParameters entries in crypto.json were changed.
• Nothing from the rest of the table is in the PR: cxfrs, google-mail-stream, hazelcast-seda, jgroups-raft, knative, jira, olingo2/4, robotframework, salesforce, solr, weather, web3j and camel-main. The controlbus-component.adoc and main.adoc edits and their catalog copies are missing too, as are the javadoc fixes in InternalProcessor/SharedInternalProcessor/CamelInternalProcessor/SharedCamelInternalProcessor.

It looks like only part of the local commit was pushed. Could you push the full change, with the source edits, and let the build regenerate the copies (mvn install -DskipTests on each touched module, then on catalog/camel-catalog, dsl/camel-componentdsl and dsl/camel-endpointdsl)? Note that #29539 changes the line next to this one in both crypto.json files, so whichever PR merges second will need a rebase and regen.

Reviewed with Claude Code on behalf of davsclaus. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[Dhairya-007]

Thanks both — you were right, only part of the change had been pushed and none of the sources. The full change is in now, 18 commits on top of the original one, one per component plus camel-main and a core commit for the javadoc that does not feed the catalog.

Sources are fixed first now. Every @UriParam/@Metadata literal and setter javadoc the generator reads is edited, so a regen no longer reverts anything: AtomEndpoint, ChatScriptEndpoint, ControlBusEndpoint, DigitalSignatureConfiguration, CxfRsEndpoint, GoogleMailStreamConstants, HazelcastSedaConfiguration, JGroupsRaftConstants, JiraConfiguration, KnativeComponent, Olingo2App/Olingo4App, RobotFrameworkCamelConfiguration, SalesforceComponent, SolrConfiguration, WeatherConfiguration, Web3jConfiguration, Web3jConstants, MainConfigurationProperties and DefaultConfigurationProperties.

The missing pieces are all added: the other 13 components, both olingo modules (which were absent entirely), the four remaining Certficates in DigitalSignatureEndpointBuilderFactory, CryptoComponentBuilderFactory, controlbus-component.adoc and main.adoc with their camel-catalog mirrors, and the IOHelper/InternalProcessor/SharedInternalProcessor/CamelInternalProcessor/SharedCamelInternalProcessor/Budget/RemoveHeadersProcessor/RemovePropertiesProcessor/CamelContextFactoryBean javadoc plus stream-caching.adoc. 91 files, 169 lines each way.

On entrys: the two reviews disagreed, and I went with @gnodet's entry's over entries. The sentence is "checks the Atom entry's updated or published date is newer than the previously read entry" — a plural noun with a singular date does not parse, and the closing clause is singular too. Say the word and I will switch it back.

What I checked, since the generated copies are updated by hand:

• Every component JSON is byte-identical to its camel-catalog copy (20 mirror pairs, including the camel-main metadata and both adocs).
• Each DSL javadoc block I touched is re-wrapped the way the generator does it: greedy to 80 columns including the * prefix. I verified the algorithm by reproducing the untouched blocks byte-for-byte, then checked all 21 touched description runs are ≤ 80 and maximally filled.
• ControlBusEndpoint.setAction's javadoc paragraph is re-wrapped too, because statistics pushed a line to 122 and the Eclipse config wraps comments at 120 (comment.line_length). Reproducing that wrap against main matched byte-for-byte. The two remaining over-128 lines in the diff, in AtomEndpoint and SalesforceComponent, are string-literal concatenations the formatter does not split; both files already carry several of those on main.
• A repo-wide scan finds no occurrence of any of the 18 misspellings left outside test fixtures. The ones left alone on purpose are the camel-cassandra.yaml, big-payload.json and MyConfiguration test data, and "base class statics" in an AS2 test, which means static fields.

I could not run the regen locally, so if CI's mvn install produces a diff I will take its patch verbatim.

On the overlap with #29539: it changes the certificateName line and this one changes keystore/keyStoreParameters right below it, both from the Java source now. Whichever merges second I will rebase and regenerate.

[gnodet-bot]

Previous findings are all addressed. LGTM.

All previous review findings are fully addressed — source Java files are now properly edited for all 17 components (plus core/javadoc fixes), and generated files are consistent with the sources. The entry's possessive fix is correctly applied as suggested. All misspellings are fixed at the annotation/javadoc source level, so a mvn generate-sources regeneration will produce the corrected text, not revert these edits.

This review was generated by an AI agent, Hermès on behalf of @gnodet.

[github-actions]

⚠️ Generated files are out of date

The CI build regenerated files that are not committed on this PR.

If Allow edits from maintainers is enabled, a maintainer bot will automatically
push a "Regen" commit to this branch shortly.

Otherwise, you can apply the patch manually — the missing changes are available
as the regen-patch artifact of that run:

gh pr checkout 29550 --repo apache/camel
gh run download 42788305279 --repo apache/camel -n regen-patch
git apply --index regen.patch && rm regen.patch pr-number
git commit -m "Regen" && git push

Alternatively, run ./etc/scripts/regen.sh locally and commit the resulting changes.
If the patch does not apply cleanly, update the branch from the base branch first —
the patch was generated against the merge with the base branch.

[davsclaus]

Thanks for pushing the full change. All the earlier points are addressed: every typo is now fixed at the source the generator reads (the @UriParam/@Metadata literals, the setter javadoc and the Olingo2App/Olingo4App javadoc), the four remaining "Certficates" in DigitalSignatureEndpointBuilderFactory and the two in CryptoComponentBuilderFactory are fixed, and the missing components, controlbus-component.adoc, main.adoc and the core javadoc are in.

I checked the generated copies statically: each component JSON and the camel-main metadata are identical to their camel-catalog copies, the two .adoc mirrors match, and every changed javadoc block in the component and endpoint DSL factories matches the generator's wrapping. None of the old spellings are left anywhere in the generated or source files (only in test fixtures, which can stay as they are).

Heads-up again: this PR and #29539 both change crypto.json (component and catalog), so whichever merges second needs a rebase and regen.

Claude Code on behalf of davsclaus. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.