Croway opened a new pull request, #127:
URL: https://github.com/apache/camel-upgrade-recipes/pull/127
Fixes #126.
The Java recipes are gated by `UsesType("org.apache.camel..*")` and the YAML
recipes by `RecipesUtil.camelYamlDslPrecondition()`. #125 added
`RecipesUtil.camelXmlDslPrecondition()` and applied it to two XML recipes; the
other ten still visited **every** XML document in a project.
That is not theoretical. `XmlDsl418_1SagaRecipe` matches `//saga` at any
depth, and in an unrelated document it does not merely rename — it removes a
child element and folds it into an attribute:
```diff
<workflow xmlns="http://example.com/schema/workflow";>
- <saga>
- <compensation uri="http://example.com/undo"/>
- </saga>
+ <saga compensation="http://example.com/undo";>
+ </saga>
</workflow>
```
This wraps every remaining XML visitor in the precondition, so the set is
now uniform and a newly added XML recipe inherits the same guard.
### Recipes gated
| Recipe | Matches |
|---|---|
| `camel40.xml.CircuitBreakerXmlDslRecipe` |
`*/circuitBreaker/resilience4jConfiguration` |
| `camel40.xml.XmlDslRecipe` | `/routes/route`, `/routes/route/description` |
| `camel41.XmlDslRecipe` | `*/bean` |
| `camel410.XmlDsl410Recipe` | `//intercept/when`,
`//interceptSendToEndpoint/when` |
| `camel418_1.XmlDsl418_1SagaRecipe` | `//saga` |
| `camel418_3.RenameHeaderPrefixInXmlDsl` | `setHeader` / `header` /
`removeHeader` tags |
| `camel47.XmlDsl47Recipe` | `//loadBalance/*` |
| `customRecipes.ReplacePropertyInComponentXml` | `//route/from`,
`//route/to` |
| `customRecipes.ReplacePropertyInDataFormatXml` | `//marshal/<component>` |
| `customRecipes.internal.ChangeXmlComponentUriRecipe` | `//route/from`,
`//route/to` |
### Tests
`CamelXmlDslPreconditionTest` adds one negative test per gated recipe, each
feeding a document that carries exactly the shape that recipe matches under a
plainly non-Camel root.
They are kept in a single class rather than spread across the existing
per-recipe test classes, because the property under test is uniform across all
of them — a newly added XML recipe is one line away from being covered, which
is a stronger regression guard than a test buried in each class. Happy to split
them if you would rather they sit next to each recipe.
**Verified the tests are not vacuous**: with the gating reverted, 8 of the
10 fail. The 2 that still pass are the recipes #125 already gated.
`camel40.xml.XmlDslRecipe` deliberately has no negative test — its matchers
are anchored at `/routes/route`, so the document root must be `routes`, which
is itself a Camel root. Noted in the class javadoc.
### One existing fixture changed
`CameXmlDslRecipeTest.circuitBreakerFull` used a synthetic
`<differentContext>` root, which is not a Camel document and so no longer
passes the gate. Its sibling `circuitBreaker` test already covers the `<route>`
context, so the root becomes `<camelContext>` — where a top-level
`resilience4jConfiguration` actually lives. The option coverage the test exists
for is unchanged.
While writing that test I found the recipe does not fire when instantiated
on its own, only when driven through the 4.0 composite the existing test uses,
so the new negative test drives it the same way. Otherwise it would have been
vacuous.
### Verification
`mvn clean install` on JDK 17, matching CI: 848 core and 12 Spring Boot
tests, no failures. No XML recipe is left ungated.
End to end on the scratch projects: the Camel 4.14 project still migrates
its XML and YAML routes and compiles against 4.22.0, and on a two-module build
the Spring bean file is untouched while `camel-routes.xml` in the same module
still 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]
