feat: Added recipe to comment deprecated and removed properties witho…

[ashakirin]

Added recipe to comment deprecated and removed properties without alternative

• Refs: Provide inline comment for deprecated and removed properties #634

[timtebeek]

Thanks for the addition already @ashakirin ! I spoke to @BoykoAlex last Thursday who had been looking for something similar for removed properties. I think this could factor in to the solution there.

As a bit of background we automatically generate recipes for properties that have moved, based on meta data available in the Spring Boot jars, as seen here:

rewrite-spring/src/test/java/org/openrewrite/java/spring/internal/GeneratePropertiesMigratorConfiguration.java

Lines 116 to 139 in 2eebf1d

	Files.writeString(config, """
	# This file is automatically generated by the GeneratePropertiesMigratorConfiguration class.
	# Do not edit this file manually. Update the Spring Boot property metadata upstream instead.
	---
	type: specs.openrewrite.org/v1beta/recipe
	name: org.openrewrite.java.spring.boot%1$s.SpringBootProperties_%1$s_%2$s
	displayName: Migrate Spring Boot properties to %1$s.%2$s
	description: Migrate properties found in `application.properties` and `application.yml`.
	tags:
	- spring
	- boot
	recipeList:""".formatted(majorMinor[0], majorMinor[1]),
	StandardOpenOption.APPEND);
	Files.writeString(config, replacements.stream()
	.map(r -> """
	- org.openrewrite.java.spring.ChangeSpringPropertyKey:
	oldPropertyKey: %s
	newPropertyKey: %s
	""".formatted(
	r.name(), requireNonNull(r.deprecation()).replacement())
	)
	.collect(joining("", "\n", "\n")),
	StandardOpenOption.APPEND);

I think we can similarly generate recipes that add comments for meta data without a listed replacement, as for instance seen here:
https://github.com/spring-projects/spring-boot/blob/32433e84f3048c397aef3c3a8d63a0ae1ca7d5fc/spring-boot-project/spring-boot-actuator-autoconfigure/src/main/resources/META-INF/additional-spring-configuration-metadata.json#L351-L359

If we are to go that route then there is no need for this recipe to include a List<String>, as matching a single key is good enough when we generate the recipes.

@BoykoAlex what are your thoughts on this?

[BoykoAlex]

@timtebeek @ashakirin I think I'm inclined to look at the recipe generation first and then come up with the appropriate shape of the recipe putting a comment. I don't know if Spring Boot Properties metadata json contains info about removed properties... Perhaps we'd need to compute removed properties based on X.Y and X.Y+1 metadata comparison? Not sure... Anyway, if it is simpler to consume removed properties one-by-one from the generator code then a single property key parameter. If it comes in as a list/collection already then a list of keys is good. To be honest a list parameter has wider usage options and likely more performant so I'd say I'm fine with its current shape... This recipe feels like its home should be rewrite-properties project under rewrite repo...

[timtebeek]

Thanks for the reply! I'd prefer to keep it here for now, as it uses ChangeSpringPropertyValue which has some Spring specific matching, and works across both Yaml and Properties.

As for removed properties I think those are called out as errors without replacements, sometimes with a reason, as shown on the link above. When there's a reason we can add that inline; if there's none then the error at least indicates a user should have a look to this likely removal.

[ashakirin]

I would like to split it in some small steps:

1. add recipes for inline comments (current PR)
2. add inline comment for deprecated properties without replacements, like @timtebeek suggested (seems to be easy)
3. analyse options for removed properties: when we can recognize them using deprecations with errors, should be trivial as well. For removed properties we can even comment the property itself + add inline comment or just leave inline comment in other format, WDYT?