Croway commented on PR #125:
URL:
https://github.com/apache/camel-upgrade-recipes/pull/125#issuecomment-5409610697
CI caught a real mistake of mine — the three `CamelSpringBoot422Test`
failures were my fault, and the fix is a revert (11a6634).
**What failed.** The transformation was correct; the assertion tripped on a
resolution marker OpenRewrite attached to the output:
```
<!--~~(Unable to download POM:
org.apache.camel.springboot:camel-ai-tool-starter:4.22.0-SNAPSHOT.)~~>-->
```
**Why it passed locally.** `@camel-spring-boot-version@` resolves to
`${project.version}` — this recipes project version, not a published Camel
Spring Boot release — so the recipes emitted
`camel-ai-tool-starter:4.22.0-SNAPSHOT`. That artifact exists in my local
repository because camel-spring-boot has been built from source there. CI has
no such artifact. A textbook works-on-my-machine.
**Why the original code was right.** Pinning is the point of a
version-specific recipe: the 4.22 recipe should introduce the artifact at the
release it appeared in. `@camel-latest-version@` would not have broken CI,
since it resolves to a released version, but it is wrong for another reason —
it tracks the newest Camel release, so once 4.23 recipes land the 4.22 recipe
would start adding `camel-ai-tool:4.23.0` to a project migrating to 4.22.
**The premise was also wrong.** I claimed Camel Spring Boot 4.22.0 was
unreleased and `camel-ai-tool-starter:4.22.0` unresolvable. Both are on
Central. That claim came from querying `org.apache.camel` instead of
`org.apache.camel.springboot`.
So the "hardcoded target versions" item is withdrawn: pinned `4.22.0` is
restored in both 4.22 recipe files and in the test assertions, and the
`camel.spring.boot.version` property plus its `CamelTestUtil` accessor — which
existed only to support the placeholders — are gone. The PR description is
updated to match; this PR is now four fixes, not five.
Verified that the fix is not masked by local state this time:
`camel-ai-tool-starter:4.22.0` is **not** in my local repository (only the
SNAPSHOT is), so the passing test resolved it from Central exactly as CI will.
`mvn clean install` on JDK 17: 828 core and 12 Spring Boot tests, no failures.
Sorry for the churn on an already-approved PR — worth a re-look at the diff
since the approval.
_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]
