Croway commented on PR #127: URL: https://github.com/apache/camel-upgrade-recipes/pull/127#issuecomment-5410485611
All four points addressed in f3e0356 — the blocking one has a detailed reply on its thread. | Point | Resolution | |---|---| | Spring-XML Camel layout rejected | A Camel namespace or `camelContext`/`routeContext` element is now conclusive at any depth; the Spring namespace only rules a document out when no Camel marker exists anywhere. Positive tests added | | `camel43.CamelResequenceEIPXmlRecipe` ungated | Gated. My survey grepped for `AbstractCamelXmlVisitor` and this one extends `XmlIsoVisitor` directly, which is exactly how it was missed — the check now covers both | | Declarative XML recipes ungated | Added `FindCamelXmlDsl`, a search-recipe form of the precondition, wired into the `preconditions:` of the 4.12 and 4.13 XML recipes | | Missing root tags | Added `camel`, `routeConfigurations`, `routeTemplates`, `templatedRoutes` | You were right about the roots being a real gap, and it was worse than the list suggested: in Camel's own `camel-xml-io-dsl` test resources, `<camel>` is the **most common** root (18 files, against 8 for `<routes>`). I checked the names against those resources rather than taking them on trust. On the declarative recipes, `furyDsl` mixes `ChangeTagName` with a Java `ChangeMethodName`, and a precondition applies to the whole recipe. I split the XML half into `camel413.furyXmlDsl` and gated that, so the Java DSL change stays ungated. `camel412.xmlDslBearer` is XML-only and took the precondition directly. One thing your review did not ask for but which fell out of doing it: widening the gate made `XmlDsl46Recipe` start corrupting Spring bean definitions that sit inside Camel documents. Details on the inline thread — short version is that it now converts only beans declaring `type=` (Camel) rather than `class=` (Spring), with a negative test. Worth a look, since it changes an existing recipe's behaviour. `mvn clean install` on JDK 17: 858 core and 12 Spring Boot tests, no failures. No XML recipe is left ungated, declarative ones included. End to end the 4.14 project still migrates and compiles against 4.22.0, and on the two-module build the Spring bean file stays untouched while the Camel route XML beside it migrates. _Claude Code on behalf of Federico Mariani_ -- 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]
