Croway opened a new pull request, #125:
URL: https://github.com/apache/camel-upgrade-recipes/pull/125
Found by applying the 4.22 recipes to three throwaway projects — Camel 4.14
(full migration chain), Camel 4.21 and Camel Spring Boot 4.21 — and inspecting
what they produced.
### `migrateOpenAiChatCompletion` could never match
`com.openai.models.ChatCompletion` only exists in openai-java 0.8.1. Every
released `camel-openai` ships a much newer SDK, where the class already lives
in `com.openai.models.chat.completions`:
| camel-openai | 4.17.0 | 4.18.x | 4.19.0 | 4.20.0 | 4.21.0 |
|---|---|---|---|---|---|
| openai-java | 4.13.0 | 4.18.0 | 4.31.0 | 4.32.0 | 4.41.0 |
No user project can hold the old import and still compile, so the recipe was
dead. Its test passed only because it pinned `openai-java-core:0.8.1` on the
parser classpath. The 4.22 guide entry describes a component metadata fix (the
declared `javaType` of the `CamelOpenAIResponse` property), so there is nothing
to migrate in user code. Recipe, test and the pinned test jar are removed.
### Headers were renamed in only some of the places they appear
`RenameHeaders` documents itself as covering "Simple expressions
(`${header.name}`) … across all DSL types", but
`RenameHeaderInSimpleExpression` only visited strings passed to `simple()`.
Applying the new atmosphere-websocket recipe left routes half migrated:
| context | before | after |
|---|---|---|
| `.setHeader("x", …)`, `getHeader("x", Class)`, `simple("${header.x}")` | ✅
| ✅ |
| `<setHeader name="x">`, YAML `setHeader: name:` | ✅ | ✅ |
| `header("x")` predicate | ❌ | ✅ |
| `.log("… ${header.x} …")` | ❌ | ✅ |
| `<simple>${header.x}</simple>`, `<log message="…">` | ❌ | ✅ |
| YAML `simple: "${header.x}"` | ❌ | ✅ |
A route that keeps reading `websocket.connectionKey` after the rename fails
silently at runtime, which is worse than the false positives the narrow scope
was guarding against. Only the complete `${header.name}` placeholder is
matched, so bare occurrences of the name and longer keys such as
`${header.kafka.TOPIC.suffix}` are still left alone.
This reverses a deliberate contract, so the `doesNotMigrateNonSimpleStrings`
test is replaced by one asserting that a Simple expression held in a variable
is migrated, plus a negative test for partial matches.
### Spring Boot applications got the non-starter artifact
`migrateLangchain4jToolsUris` adds `org.apache.camel:camel-ai-tool`, which
brings no auto configuration in Spring Boot. On a project that also had
`camel-spring-ai-tools-starter`, the result was both artifacts side by side.
The new `migrateAiToolStarterDependency` runs after the Camel recipe, swaps the
plain artifact for `camel-ai-tool-starter` and removes the duplicate when the
starter is already declared.
### Target versions were hardcoded
Three recipes pinned `4.22.0` literally, which goes stale on the next
release and disagreed with the `camel.version` the Spring Boot chain writes.
They now use the `@camel-latest-version@` / `@camel-spring-boot-version@`
placeholders that the existing resource filtering resolves.
`camel.spring.boot.version` is added to `versions.properties` with a
`CamelTestUtil` accessor so the tests assert against the build's version rather
than a literal.
### YAML endpoint options inlined in `uri:` were skipped
`ReplacePropertyInComponentYaml` only rewrote the `parameters:` mapping,
while `ReplacePropertyInComponentXml` already handled both forms, so the same
route migrated differently depending on the DSL:
```yaml
- uri:
"netty-http:https://0.0.0.0:9443/service?keyStoreFile=/opt/keystore.jks";
+ uri:
"netty-http:https://0.0.0.0:9443/service?keyStoreResource=file:/opt/keystore.jks";
```
It now reuses the `RecipesUtil.replacePropertyInUrl` helper the XML variant
uses.
### Verification
`mvn clean install` on JDK 17: 820 core tests and 11 Spring Boot tests, no
failures. New tests cover each fix.
Re-applied to the three test projects afterwards: the header renames are now
complete across Java, XML and YAML; the Spring Boot pom ends up with a single
`camel-ai-tool-starter` and no hardcoded version; and the Camel 4.14 project
still compiles cleanly against 4.22.0 after the full migration chain.
### Left alone deliberately
For a project importing an AWS SDK BOM older than 2.46.0,
`migrateAwsApacheClient` renames `apache-client` to `apache5-client` without
bumping the BOM, so it resolves to `2.34.6-PREVIEW` rather than GA. That
matches the recipe's documented "BOM-managed dependencies keep their managed
version" contract, and changing it would mean overriding the user's BOM. Worth
a line in the description, but not a change I would make unprompted.
---
_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]
