Croway opened a new pull request, #140: URL: https://github.com/apache/camel-upgrade-recipes/pull/140
Closes #129. Camel 4.22.x is the current LTS line (the Camel site lists 4.22.2 as `kind: lts`, EOL 2027-08-10). Since `latest.yaml` moved to 4.23, no recipe sets a project to 4.22.x. This PR adds the 4.22 counterparts of the 4.18 LTS aggregates. #129 was waiting for a second 4.22.x patch release, and 4.22.2 is now on `main`. ## Recipes | Module | Recipe | Chain | Target | |---|---|---|---| | `camel-upgrade-recipes` | `Camel422LTSMigrationRecipe` (`4.22LTS.yaml`) | `camel422_2` → `camel422_1` → `camel422` → … → `camel40`, Java 17, property keys | Camel `4.22.2` | | `camel-spring-boot-upgrade-recipes` | `CamelSpringBoot422LTSMigrationRecipe` (`4.22LTS.yaml`) | target-version bumps first (as in `latest.yaml`) → `camel422_2` → `camel422_1` → `camel422.CamelSpringBootMigrationRecipe` | Camel / Camel Spring Boot `4.22.2`, Spring Boot `4.1.x` | There is a new `camel4.22-lts-version` property (`4.22.2`) in the parent POM, a matching `versions.properties` key, and `CamelTestUtil.getCamel422LtsVersion()`. This only works because of the 4.23 change that moved every Camel target-version bump into the aggregates (`TargetVersionOnlyInAggregatesTest`): no chained version recipe pins the project to 4.23. ## Spring Boot targets Camel Spring Boot 4.22.x and the latest release are on the same Spring Boot 4.1.x line (Camel `parent/pom.xml` has `spring-boot-version` 4.1.1 at both `camel-4.22.2` and `camel-4.23.0`). So the SB aggregate reuses `@spring-boot-version@` / `@springframework-version@` instead of adding `*-4.22-lts-version` properties. Separate properties would only look independent: the Spring Boot 3→4 migration chained through `camel419.CamelSpringBootMigrationRecipe` already moves to the latest Spring targets, and `UpgradeDependencyVersion` never downgrades. `CamelSpringBoot422LtsVersionTest.springBootParentMovesToTheLtsLine` is a guard for this. It asserts only the `4.1.` prefix, so Spring Boot patch bumps don't break it, and it fails as soon as the latest Spring Boot target leaves 4.1.x. At that point the 4.22 LTS needs its own Spring targets. I checked that it fails as intended by rebuilding with `-Dspring-boot-version=4.0.5` (`spring-boot-starter-parent upgraded to 4.0.5, expected the 4.1.x line of camel-spring-boot 4.22.2`). The pom comment next to `spring-boot-version` points to it. ## Tests - `CamelUpdate422LtsTestSuite`: the 4.18 LTS suite's class list plus `CamelUpdate419Test` … `CamelUpdate422_2Test`, run against `Camel422LTSMigrationRecipe`. Result: 235 tests, 0 failures. The 41 skips are the usual `@DisabledIfSystemProperty(... useRecipe ...)` tests. - `CamelUpdate422LtsVersionTest`: `camel.version` 4.10.0 → 4.22.2 under the suite. - `CamelSpringBoot422LtsVersionTest`: property-managed and literal camel-spring-boot BOM, the `org.apache.camel.springboot:spring-boot` parent (4.18.5 → 4.22.2, not 4.23.0), and Spring Boot 3.5.16 → 4.1.x. The parent case also gets a `<javaVersion>17</javaVersion>` override from the Java 17 step of the 4.19 chain, because the property is inherited from the Apache parent POM with an older value. The test documents this instead of hiding it. - Full `mvn clean install`: core 1172 tests and Spring Boot 28 tests, 0 failures. README (usage for both new recipes) and `release_notes.adoc` (new `4.24.0` section) are updated. _Claude Code on behalf of croway_ -- 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]
