k-krawczyk commented on PR #25409:
URL: https://github.com/apache/camel/pull/25409#issuecomment-5231050538
Thanks @atiaomar1978-hub — the inline findings were all correct and are
fixed in 376bf6a65. I verified each one against the templates rather than
taking them at face value, and each held up:
- **Packaged layout (java, main).** Both archetypes declare
`packaged="true"` on the `src/main/java` fileSet, so the generated classes land
under `src/main/java/<package>/`. The readme and `AGENTS.md` now say so. This
one is embarrassing on my side: I had the generated trees in front of me when
verifying the original change and never diffed them against the paths I had
written.
- **No route scanning in the java archetype.** `MainApp` registers
explicitly with `main.configure().addRoutesBuilder(new MyRouteBuilder())`, so
the scanning clause is gone and the guidance points at that call instead.
- **Data format registration.** The template carries
`@org.apache.camel.spi.annotations.Dataformat("${scheme}")` and has no
`META-INF/services` file, so `AGENTS.md` now documents the annotation and
keeping `getDataFormatName()` in sync.
- **api-component clarity.** Split as suggested: the plugin-generated API
proxies must not be hand-edited, while the endpoint and configuration classes
under `*-component/src/main/java` are hand-written and carry `@UriEndpoint` /
`@UriParam`.
Re-verified after the change: archetypes rebuild, `apache-rat-plugin:check`
reports 0 unapproved across all seven modules, and I regenerated the `java` and
`main` projects to compare the documented paths against the actual tree.
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 coverage
You 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.** `goal.txt` for `build-it` is
`install`, so the IT does not just generate a project, it builds it with Maven:
resolving dependencies and compiling the generated sources. On top of that
`archetype.properties` carries a TODO pointing at ARCHETYPE-574, and
`archetype.test.skip=true` is set in the `skipTests`, `fastinstall` and
`release` profiles. This looks deliberately disabled rather than forgotten, so
re-enabling it is a CI cost decision for a committer, not something I want to
slip into a docs PR.
**Option B — a JUnit smoke test in the archetype modules.** This does not
run at all today. I added a trivial test and executed `mvn test` on
`camel-archetype-java`: with `packaging=maven-archetype` the `test` phase runs
eight goals — enforcer, license, formatter, impsort, `resources`,
`generate-and-attach-archetype-catalog`, `testResources` — and neither
`compiler:testCompile` nor `surefire:test` is among them. The test is never
compiled, let alone executed. Making it work needs explicit plugin bindings
added to the archetype poms.
**What I would suggest instead.** The bug class here is a mismatch between
`archetype-metadata.xml` and the files on disk. That is checkable without
generating or building anything: parse each `archetype-metadata.xml`, resolve
every `<fileSet>` directory plus its concrete `<include>` entries against
`archetype-resources/`, and assert that each one exists and that `README.md`
and `AGENTS.md` are declared somewhere. Milliseconds, no network, no new
dependencies — and it would have failed on the api-component bug before this PR.
It still needs somewhere to live, which means either adding `testCompile`
and `surefire` bindings to the six archetype poms, or a small `jar` module
under `archetypes/`. That is a structural change to the archetypes module and
belongs in its own ticket rather than here. I am happy to open a follow-up JIRA
and implement it — just say which placement you would accept.
_Reported by Claude Code on behalf of Karol Krawczyk_
--
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]
