I was hoping to use the Spring Boot Properties Migrator to help me migrate from non-ConfigurationProperties (simply referenced via @Value) to proper ConfigurationProperties, which unfortunately means that I have to rename them all.
I'm using the spring-boot-configuration-processor to automatically generate the spring-configuration-metadata.json for the new properties and I was manually editing the additional-spring-configuration-metadata.json to list the old deprecated properties and their replacement. And this almost works. Eclipse now marks old property keys as deprecated and the tooltip shows me the replacement. But what I really need are the runtime checks (I configured the deprecations as errors) provided by the spring-boot-properties-migrator. But as it turns out, the PropertiesMigrationListener only loads spring-configuration-metadata.json, but NOT additional-spring-configuration-metadata.json. Could the PropertiesMigrationListener be changed to also consider additional-spring-configuration-metadata.json or is there a reason it doesn't already do that?
Comment From: snicoll
@Frettman additional-spring-configuration-metadata.json is merged into spring-configuration-metadata.json at build-time. If you have a module with no generated keys, there is no need to name your custom file additional-spring-configuration-metadata.json. Just name it spring-configuration-metadata.json and you'll be good to go.
If you're expecting the additional file to be loaded, it shouldn't. If the above doesn't help you, we'll need a small sample that demonstrates the problem to understand what you're trying to do.
Comment From: Frettman
Thank you, knowing the simple fact that they are merged has helped me a lot. Knowing how it should work at runtime made it easier to look at the right locations for problems. The typical Eclipse hickups (where in this case it stopped updating spring-configuration-metadata.json) also didn't help. Anyway, thanks for clearing this up and sorry for wasting your time.