3.0.0-M5: Redis Properties

[fabapp2]

labels: ["type: enhancement","good first issue","upgrade:boot-recipe","3.0.0"]

From the Release Notes

Configuration Properties for Redis have moved from spring.redis. to spring.data.redis. as redis auto-configuration requires Spring Data to be present on the classpath.

What needs to be done

Find all properties with prefix spring.redis. and change the property to use the prefix spring.data.redis..

This should be done as (integrated) declarative plain OpenRewrite recipe

See:

spring-boot-migrator/components/sbm-recipes-boot-upgrade/src/main/resources/recipes/boot-2.7-3.0-dependency-version-update.yaml

Lines 82 to 95 in f219382

	- type: org.springframework.sbm.engine.recipe.OpenRewriteDeclarativeRecipeAdapter
	condition:
	type: org.springframework.sbm.boot.common.conditions.IsSpringBootProject
	versionPattern: "3\\.0\\..*"
	description: Migrate SAML configuration to Spring Boot 3.0 in yaml format
	openRewriteRecipe: |-
	type: specs.openrewrite.org/v1beta/recipe
	name: org.openrewrite.java.spring.boot2.SpringBootPropertiesManual_2_7
	displayName: Migrate SAML configuration to Spring Boot 3.0 in yaml format
	description: Renames spring.security.saml2.relyingparty.registration.(any).identityprovider to spring.security.saml2.relyingparty.registration.(any).assertingparty.
	recipeList:
	- org.openrewrite.yaml.ChangeKey:
	oldKeyPath: $.spring.security.saml2.relyingparty.registration.*[?(@.identityprovider)]
	newKey: assertingparty

[kuldeepsidhu88]

@fabapp2 I can work on this. Can you please assign this to me.

[fabapp2]

Hi @kuldeepsidhu88

First of all, thanks for contributing to SBM 🚀

OpenRewrite has recently solved the problem of reading property changes from metadata information contained in jars.
Property changes in Spring Boot are documented in a spring-configuration-metadata.json file and they read them from the jars of the relevant version to create property update recipes out of these files.
This means we'd be reinventing the wheel with more recipes for property updates.

I haven't yet looked into it in detail but I guess I'll need to upgrade to the latest Rewrite to use their solution for migration recipes. That's on my list and I'd like to wait and see if we can reuse their recipe before we provide more of these recipes ourselves.

We decided to go "report-first" for now, so these changes should also be provided in a report (first).
I would like to see if we can use a similar (or even their) approach to generate the report section(s) that highlight relevant property changes in the report to users. If this works we could skip all property updates (migration & report) and generate them from the metadata information.

Looking at your timestamp makes me think we're in different time zones. Meaning I will try to provide more issues (and probably close some old ones) to reflect our "report-first" approach in the (currently bit messy) backlog today (🤞).
I am still lacking behind but I will try to provide an issue that would be more important at the moment, hoping you might be willing to look into it instead. (🤞)

[kuldeepsidhu88]

Sure @fabapp2
Please let me know which issue can be picked next, I would be happy to contribute.

[fabapp2]

Hi @kuldeepsidhu88

I am starting to clean up the backlog.
If you like, #248 would be something to look into. I am still experimenting with an unified issue format for creating report sections and migrations of changes described in the Release Notes but I hope provided information is sufficient for a start 🤞

[kuldeepsidhu88]

@fabapp2 Okay, I will start looking into #248