CAMEL-23701: Make generated archetype projects more AI-relevant - #25409
Conversation
orpiske
left a comment
There was a problem hiding this comment.
I did a quick manual review and it looks good to me. Thanks @k-krawczyk !
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
davsclaus
left a comment
There was a problem hiding this comment.
Nice work — this is a clean, well-structured PR that follows the pattern established by #24063 (JBang export). The camel-archetype-api-component bug fix is confirmed valid (the ReadMe.txt was declared in the __artifactId__-component/ fileSet but the file lives at the project root, so no readme was ever generated).
One required change: the upgrade guide entry needs to move to the 4.23 guide since 4.22.0 is being built and released. The camel-4x-upgrade-guide-4_23.adoc file doesn't exist yet, so it will need to be created.
Minor suggestions (non-blocking):
- The
camel-archetype-springAGENTS.mdcould mention that this archetype is deprecated and suggest Spring Boot instead, so AI agents don't invest effort in a deprecated project unknowingly. - The
camel-archetype-dataformatAGENTS.mdreference link points towriting-components.html— inherited from the old readme and probably the closest available page, but slightly off-target for data formats.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
|
Just mind that 4.22.0 is released soon so this PR will go into 4.23. But we need to wait until main branch has been prepared for this. |
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 7 tested, 0 compile-only — current: 6 all testedMaveniverse Scalpel detected 7 affected modules (current approach: 6).
|
|
Thanks @davsclaus, @orpiske, @oscerd and @Croway for the reviews. All three points are addressed in f9b9947. Required change — upgrade guide moved to 4.23. The entry is now in a new On the timing: I created the 4.23 guide here so the PR is complete, but I understand the merge should wait until Suggestion 1 — deprecated Spring archetype. Both the Suggestion 2 — data format link. The Re-verified after the change: archetypes rebuild, Reported by Claude Code on behalf of Karol Krawczyk |
atiaomar1978-hub
left a comment
There was a problem hiding this comment.
Code review (Bugbot + Grok)
AI-generated review on behalf of @atiaomar1978-hub
Solid follow-up to CAMEL-23702 / #24063 — the README.md + AGENTS.md direction for archetypes is exactly what AI-assisted contributors need. The api-component readme fileSet fix is a real bug fix (verified: readme was silently dropped). Velocity left unfiltered for # headings is the right call.
Bugbot: no bugs found.
Grok + manual check: a few doc accuracy issues undermine the AI-guidance goal — mostly packaged path layout in java/main archetypes and one incorrect registration hint. Details in inline comments.
Verdict: Request changes on the inline items; happy to re-review once fixed and CI is green.
|
|
||
| ## Project layout | ||
|
|
||
| - `src/main/java/MyRouteBuilder.java` — the Camel routes. |
There was a problem hiding this comment.
These paths omit the package directory. The java sources fileSet uses packaged="true", so generated projects place classes under src/main/java/<package>/MyRouteBuilder.java and .../MainApp.java, not at the src/main/java/ root.
Please use <package>/MyRouteBuilder.java (or src/main/java/<package>/...) so agents don't create default-package files.
|
|
||
| ## Conventions | ||
|
|
||
| - Add routes as `RouteBuilder` classes and register them with `Main` (or let component scanning pick them up). |
There was a problem hiding this comment.
MainApp registers routes explicitly via main.configure().addRoutesBuilder(new MyRouteBuilder()) — there is no component/package scanning in this archetype.
Suggest: "Add routes as RouteBuilder classes and register them on Main the same way as MyRouteBuilder." Drop the scanning clause to avoid misleading agents.
| # Camel Java Router Project | ||
|
|
||
| A standalone Apache Camel application generated from the `camel-archetype-java` Maven archetype. | ||
| Routes live in `src/main/java/MyRouteBuilder.java` and are started by `src/main/java/MainApp.java`. |
There was a problem hiding this comment.
Same packaged-layout issue as AGENTS.md: with packaged="true", routes and MainApp live under src/main/java/<package>/, not directly under src/main/java/. Align README with the actual generated tree.
|
|
||
| ## Project layout | ||
|
|
||
| - `src/main/java/MyRouteBuilder.java` — the Camel routes. |
There was a problem hiding this comment.
The main archetype also uses packaged="true" for Java sources. Listing flat src/main/java/MyRouteBuilder.java, MyApplication.java, etc. will mislead agents — please document src/main/java/<package>/... (same for the test class on line 18).
|
|
||
| ## Conventions | ||
|
|
||
| - Implement both `marshal` and `unmarshal`, and stream from the given `InputStream`/`OutputStream` instead of buffering whole messages where possible. |
There was a problem hiding this comment.
Worth adding the actual registration hook from the generated template: @org.apache.camel.spi.annotations.Dataformat("<scheme>") on the DataFormat class (plus keeping getDataFormatName() in sync). This archetype does not use a META-INF/services file — agents may invent one without this hint.
| ## Conventions | ||
|
|
||
| - The endpoint configuration and the API method proxies are generated at build time from the API signatures — change the API or the signature files rather than editing generated sources. | ||
| - Annotate the endpoint with `@UriEndpoint` and its options with `@UriPath`, `@UriParam` and `@Metadata`. |
There was a problem hiding this comment.
Minor clarity: line 27 says proxies/config are generated — this line then says "Annotate the endpoint with @UriEndpoint..." which could imply editing generated code.
Suggest splitting: hand-written endpoint/configuration classes may use @UriEndpoint / @UriParam; generated API proxies and collections from camel-api-component-maven-plugin should not be hand-edited.
| See the xref:camel-upgrade-recipes-tool.adoc[documentation] page for details. | ||
| ==== | ||
|
|
||
| == Upgrading Camel 4.22 to 4.23 |
There was a problem hiding this comment.
Creating/linking the 4.23 upgrade guide while main is still on 4.22.0-SNAPSHOT may be premature (see @davsclaus feedback on similar PRs). Fine to keep the file in this PR, but consider holding merge until main is bumped to 4.23 — otherwise the index advertises a 4.23 guide from a 4.22 tree.
Test coverage follow-upAI-generated on behalf of @atiaomar1978-hub Checked automated test coverage for this PR — no test files are added or modified. Verification is manual only (as noted in the PR description). That gap is worth addressing given the api-component readme regression this PR fixes. Current state
What manual verification covers (per PR)✅ What is not guarded by CI
Suggestions (pick one — ordered by ROI)Option A — Minimal archetype IT (recommended) This would have caught the pre-4.22 api-component bug automatically. Option B — Shared unit test in Option C — Follow-up JIRA Verdict on test coverageInsufficient for merge without follow-up — acceptable for docs-only archetype change if manual verification is repeated each release, but not ideal for a change whose main bug was silent fileSet misconfiguration. Recommend Option A or B in this PR or an immediate follow-up before 4.23. Happy to re-review if tests are added. |
| </includes> | ||
| </fileSet> | ||
|
|
||
| <!-- project root docs --> |
There was a problem hiding this comment.
Test coverage: This fileSet fix is exactly the kind of regression automated archetype ITs would catch — before this PR, ReadMe.txt was listed under artifactId-component/ while the file lived at project root, so no readme was generated (reproduced on 4.21.0). Consider adding/re-enabling a build-it archetype IT that asserts README.md and AGENTS.md exist at the generated project root.
| @@ -0,0 +1,27 @@ | |||
| # AGENTS.md | |||
There was a problem hiding this comment.
Test coverage: No automated test validates generated AGENTS.md presence or content. JBang ExportTest already asserts AGENTS.md exists after export (#24063). Archetypes have IT scaffolding under src/test/resources/projects-disabled/ but it is disabled — a minimal smoke IT per archetype would lock this in.
|
Thanks @atiaomar1978-hub — the inline findings were all correct and are fixed in 376bf6a. I verified each one against the templates rather than taking them at face value, and each held up:
Re-verified after the change: archetypes rebuild, On the 4.23 upgrade guide — agreed, and that matches @davsclaus. The file is here so the PR is complete; if you would rather it landed with the branch preparation, I will drop it and rebase. On test coverageYou are right that this change is unguarded, and that the api-component fileSet bug is exactly what an automated check should have caught. I looked into both of your options before answering, and neither works as written: Option A — enabling the archetype ITs. Option B — a JUnit smoke test in the archetype modules. This does not run at all today. I added a trivial test and executed What I would suggest instead. The bug class here is a mismatch between It still needs somewhere to live, which means either adding Reported by Claude Code on behalf of Karol Krawczyk |
Bugbot & Grok Re-Review ReportAI-generated review on behalf of the operator. PR: CAMEL-23701 — Make generated archetype projects more AI-relevant Executive summaryThis is a clean follow-up to CAMEL-23702 / #24063 (JBang export). All six archetypes now emit Prior review threads (packaged paths, java no-scan, Bugbot findingsMust-fix
No blocking bugs in generated markdown or metadata at HEAD. Should-fix
Nice-to-have
Grok findingsDesign assessment
Prior fixes verified at HEAD (
|
| Issue | Status |
|---|---|
| Packaged layout paths (java, main) | ✅ Fixed — src/main/java/<package>/... |
| Java archetype: no route scanning | ✅ Fixed — explicit addRoutesBuilder |
Data format: @Dataformat annotation, no META-INF/services |
✅ Fixed |
| api-component: generated vs hand-written split | ✅ Fixed |
| Spring deprecation notice | ✅ Fixed |
| Upgrade guide moved to 4.23 | ✅ Fixed |
What looks good
- Drive-by api-component fileSet fix prevents silent readme omission
- Manual verification documented (
archetype:generate×6, token checks, URL 200 checks) - Content checked against actual generated trees (not generic boilerplate)
- Consistent AGENTS structure across all six archetypes
- No Velocity interpolation risk in markdown headings
Test coverage (re-confirmed)
| Area | Status |
|---|---|
| Test files changed | 0 |
| Archetype ITs | Under projects-disabled/ — not run in CI |
| JBang precedent (#24063) | ExportTest asserts AGENTS.md / readme.md — archetypes have no equivalent |
| Author's Option A (enable ITs) | Blocked: build-it runs full install, ARCHETYPE-574, archetype.test.skip=true |
| Author's Option B (JUnit in archetype poms) | Blocked: packaging=maven-archetype skips surefire today |
| Suggested follow-up | Metadata-vs-disk validation (no generate/build) — good JIRA candidate |
Verdict on tests: Acceptable for docs-only change with manual verification, but not ideal given the bug class. Track follow-up JIRA before 4.23.
Recommended actions
- Before merge: Wait for 4.23 branch prep (@davsclaus)
- Author: Fix main archetype AGENTS package-scan guidance; reword dataformat writing-components link
- Reviewers: Resolve fixed inline threads; re-request review on HEAD
- Follow-up JIRA: Archetype metadata fileSet validation test (author proposal)
Bottom line: Ready to approve once 4.23 timing is right and the two remaining AGENTS doc gaps are addressed (or tracked as follow-ups). The api-component fix and AGENTS.md direction are valuable contributions.
davsclaus
left a comment
There was a problem hiding this comment.
Nice work on this PR — the archetype modernization and the AGENTS.md additions are well done, and the api-component readme bug fix is a real fix (confirmed that ReadMe.txt was declared in the __artifactId__-component/ file set but lived at project root, so no readme was ever generated).
Highlights:
- Each
AGENTS.mdis properly tailored to its archetype (api-component describes the multi-module layout and signature files; dataformat describes marshal/unmarshal conventions; spring notes the deprecation). - The unfiltered file sets for
.mdfiles correctly avoid Velocity interpreting Markdown#headings as directives. - Upgrade guide entry is clean and follows the existing pattern.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
Rename ReadMe.txt to README.md in all six Camel archetypes and rewrite the content in Markdown, with the documentation links refreshed to https. Each generated project now also gets an AGENTS.md with guidance for AI coding assistants: the Apache Camel LLM index (https://camel.apache.org/llms.txt), the .html -> .md documentation trick, a pointer to the Camel CLI and the Camel MCP server, plus the project layout, the build/run commands and the conventions that apply to that archetype. This also fixes camel-archetype-api-component, which declared its readme in the __artifactId__-component file set while the file lives at the project root, so no readme was generated at all. Co-authored-by: Claude <noreply@anthropic.com>
Move the upgrade guide entry to a new camel-4x-upgrade-guide-4_23.adoc, as 4.22.0 is being released and this change ships in 4.23, and link the new guide from the upgrade guide index. Also apply the two review suggestions: the camel-archetype-spring readme and AGENTS.md now say that the archetype is deprecated and point at Camel on Spring Boot or the Camel CLI, and the camel-archetype-dataformat docs reference the data format manual page next to the writing-components page. Co-authored-by: Claude <noreply@anthropic.com>
…layout The java and main archetypes use packaged="true" for their Java sources, so the generated classes live under src/main/java/<package>/ and not directly under src/main/java. The readme and AGENTS.md now say so, otherwise an agent would create default-package files. The java archetype does not scan for routes either: MainApp registers them explicitly with main.configure().addRoutesBuilder(...), so the guidance no longer mentions scanning. The data format archetype registers itself through the @DataFormat annotation on the class rather than a META-INF/services file, which is now documented together with keeping getDataFormatName() in sync. For the api-component archetype the guidance separated the generated API proxies, which must not be hand-edited, from the hand-written endpoint and configuration classes that carry the @UriEndpoint and @UriParam annotations. Co-authored-by: Claude <noreply@anthropic.com>
376bf6a to
eb9e426
Compare
|
Rebased onto There was exactly one conflict, an add/add on Two follow-on effects of
Nothing outside the upgrade guide changed in the rebase: the diff against The verification section in the description was run before the rebase, against @davsclaus — you noted that this should wait until Reported by Claude Code on behalf of Karol Krawczyk |
Summary
Applies the same treatment as CAMEL-23702 (#24063), but to the Maven archetypes instead of the JBang export.
ReadMe.txttoREADME.mdin all six archetypes and rewrites the content in Markdown, with the documentation links refreshed tohttpsand to the currentcamel.apache.org/manual/writing-components.htmllocation.AGENTS.mdto every generated project: the Apache Camel LLM index (https://camel.apache.org/llms.txt), the.html->.mddocumentation trick, a pointer to the Camel CLI and the Camel MCP server with an explicit "do not invent component URIs or options" instruction, plus the project layout, the build/run commands and the conventions of that archetype.archetype-metadata.xmlfile sets accordingly — the readme is listed explicitly there, so the rename alone would have silently dropped it.camel-archetypesentry to the 4.23 upgrade guide. When this PR was opened,camel-4x-upgrade-guide-4_23.adocdid not exist yet and the PR created it;mainhas since been prepared for 4.23 and created the file itself, so after the rebase this PR only adds a section to it.camel-archetype-springstates in both generated files that the archetype is deprecated, pointing at Camel on Spring Boot orcamel init.Drive-by fix
camel-archetype-api-componentdeclared its readme in the__artifactId__-component/file set while the file actually lives at the project root, so no readme was generated at all. Reproduced against the released archetype:produces a project with
pom.xmland the two modules, and no readme. This PR moves the entry to a root file set, so the readme is generated again.Notes
The
.mdfile sets are deliberately left unfiltered, asReadMe.txtwas. Markdown headings start with#, which is the Velocity directive prefix, so the generated docs are kept free of interpolation rather than risking mangled output. Consequently the content uses no${artifactId}-style placeholders.Verification
./mvnw install -Dquickly -f archetypes/pom.xml— BUILD SUCCESS.mvn archetype:generaterun for all six archetypes against the locally installed4.22.0-SNAPSHOT:README.mdandAGENTS.mdare generated at the root of every project, with no unresolved${...}or__x__tokens.MainApp/MyRouteBuilder,MyApplication/MyBean/MyConfiguration,camel-context.xml,META-INF/services/.../<scheme>, theDataFormatimplementation), so it does not describe files that are not there.apache-rat-plugin:checkon the archetypes module: 0 unapproved (**/*.mdis excluded in the root POM)..mdvariant of the manual page.The archetype integration tests under
src/test/resources/projects-disabledare disabled, so verification was done by generating projects manually as described above.Reported by Claude Code on behalf of Karol Krawczyk