Separating application.properties into different files based on profile

[ishish07]

What's changed?

I added 1 recipe to split application.properties files into multiple application-profile.properties files if additional profiles are specified and separated by either #--- or !---

This recipe also deletes the additional profile configurations in the application.properties file itself as it would be replaced by a new file.

What's your motivation?

During my internship this summer, I had to manually create new application-environment.properties files based on the profiles and/or environments that were specified in application.properties. This was during our migration to Java 21. We were doing this for organizational purposes.

Anything under #--- or !--- in application.properties belongs to a different document. If there are global properties under #--- or !---, those configurations will not be applied to other profiles and/or environments and could cause bugs. By running this recipe and separating application-env.properties files, it becomes obvious if there are missing global properties in application.properties.

Anything in particular you'd like reviewers to focus on?

I would like the reviewers to focus on whether the file path to the newly created application-env.properties files is accurate. These new files belong in the same folder that application.properties exists in.

I would also like the reviewers to see if there is any way to add a helpful comment when appending properties into an existing application-profile.properties file. I append new content on line 92 in the appendToExistingPropertiesFile method. I was not sure how to add a comment as we are dealing with Properties.Content instances. It would be nice to add something like

"# Below are the properties from application.properties!"

The third thing I'd like reviewers to focus on is whether there is an easy way to have the code do nothing if no application.properties file is found. I was trying to use Precondition.check in getScanner but I wasn't able to get it to work. There are a few if statements littered around the code just to deal with the case that the application.properties file doesn't exist, so it would make the code a lot more clean if it could just do nothing when it detects that in the scanner.

Thank you!

Any additional context

Most likely, respositories will not maintain a profile specific section in application.properties along with an existing application-profile.properties file. However, I felt it would be safe to keep this edge case in mind. I wrote the recipe to safely append content to its corresponding pre-existing application-profile.properties file - otherwise the recipe would run and harmfully delete configurations.

Checklist

• [x] I've added unit tests to cover both positive and negative cases
• [x] I've read and applied the recipe conventions and best practices
• [x] I've used the IntelliJ IDEA auto-formatter on affected files

[timtebeek]

Thanks a lot @ishish07 ! I like how you've sketched the context of having had to do this by hand, and now wish to automate this for others going forward. I'll need to take a closer look & go over the focus areas you've identified, but expect we can get this in somewhere this week.

[github-actions[bot]]

This PR is stale because it has been open for 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[timtebeek]

as discussed we'd need to cover multi module projects before we can merge; let us know if you'd need any help on that front.