Allow properties file lookup for multiple names similar to multiple profiles

[goatfryed]

There seems to be a reoccurring demand to externalize default configurations per library in multi project builds.
Currently, the go to solution seems to be via spring.config.additional-location which is not profile dependent and can get quite verbose.

I therefore propose to add support for additional configuration names. This should be provided by something like spring.config.additional-names.
It would be interesting to also utilize this in @EnableMyModule annotations in some way, but I leave this as an follow up discussion for now.

The setting should repeat the normal property lookup behavior for all mentioned names. That is, a file path {lib-name}.yaml or .properties would overshadow a classpath file and profile specific files would override in usual order. The profile should have precedence over the name. The order should be low to high as for profiles, with the main name taking highest precedence.
This means for name=application; additional-name=lib1, lib2; profiles=prod,local the precedence should be application-local.properties > lib2-local.properties > application-prod.properties > lib2-prod.properties > lib1-prod.properties > application.properties > lib1.properties

What would this feature solve?

See the following s/o questions for proof of demand
https://stackoverflow.com/questions/33229793/how-to-add-multiple-application-properties-files-in-spring-boot
https://stackoverflow.com/questions/25855795/spring-boot-and-multiple-external-configuration-files/25862357#25862357
https://stackoverflow.com/questions/30198688/merge-many-application-properties-files-instead-of-replace-on-spring-boot/30213550#30213550

Especially in cloud projects, I have the reoccurring wish to extract packages into independent libraries and provide sensible defaults for the profiles test, dev and prod as well as default. I also like to place them in respective application.yaml files as it doubles as a nice one-glance-documentation of settings.
To provide them to the consumer app, I also rename these config names per library. But to consume them, I then need to specify additional-location.
So I have to require and ensure that for every profile there is a corresponding consumer-{profile}.yaml file that references all {library}-{profile}.yaml files that exist.

Although, I assume overshadowing of property files got more rare these days, if someone also wants to override the consumer-{profile}.yaml, they'd also have to re-reference the {library}-{profile}.yaml files. And if they want to overshadow the {library}-{profile}, they have to overshadow both, to ensure the additional-location of consumer.yaml is overriden and not added.

Impact on spring eco system

I think, In general this could have a positive impact on the spring eco system, as it would be possible to provide nice, sensible defaults for common profiles in libraries to further easy developer experience.

[wilkinsona]

@goatfryed Thanks for the suggestion. We'd like to make the discovery of configuration files more extensible and #24688 is tracking that work. I'll add a comment to that issue so that we consider your particular use case as a part of it.