It's very easy to mistype a spring.config.import and have it silently fail. It would probably be better to throw an exception by default and have another signal for optional locations.
Comment From: jeffbswope
Just a thumbs-up for some mechanism/signal to provide support for optional includes...
We have launchers where we include some optional file locations now in via command-line --spring.config.additional-location and I could see how we could end up replacing/augmenting that using optional config locations in spring.config.import...
This might raise the question if the "file-not-folder" usages of spring.config.location/spring.config.additional-location would benefit from harmony with whatever default-optional behavior ends up in spring.config.import? Or does it help to keep them more clearly distinct and different in another way?
Comment From: philwebb
I've gone for a prefix of optional: to indicate an optional location. You can use it with spring.config.location, spring.config.additional-location and spring.config.import directives.
This might raise the question if the "file-not-folder" usages of spring.config.location/spring.config.additional-location would benefit from harmony with whatever default-optional
I think it does, although it might cause a few people some issues with upgrades since they'll need to add an optional: prefix to their commands. On the whole, I think it's better to be explicit about optional locations. I think previously it was too easy to make a typo and not understand why properties weren't loaded.