SpringBoot Add resource hints for application properties

This issue is about adding resource hints for application properties files, including: - both .properties, .yml and yaml variants - supporting suffixed versions like application-profile.properties

The related generated configuration by Spring Native is:

      {
        "pattern": "^application.*.properties"
      },
      {
        "pattern": "^application.*.yaml"
      },
      {
        "pattern": "^application.*.yml"
      },

Comment From: snicoll

This one is interesting as we support imports of additional files that can have any naming convention. I suppose we could look at the Environment built at build-time and figure out what files were processed?

Comment From: philwebb

We might be able to use the Origin of the property source. I wonder how many users will have .properties or .yaml files in their app that they don't want to read? Perhaps we should flip it around and include all .properties and .yaml unless an AOT processor indicates that they've been handled.

Comment From: philwebb

We discussed this a little today and we think it's best not to put too much intelligence in the AOT processors. We're especially worried that trying to analyze application.properties files in order to determine import or template configuration (see #31310) will be quite brittle and hard for users to understand.

We're leaning towards having a clearer distinction between the runtime behavior and the build time behavior. We think that having the build plugin configure the resources that are included/excluded with sensible defaults will probably be the best approach.

We're especially keen to ensure that we can support profiles sometime in the future.

Comment From: philwebb

As a concrete example, supports the user has the following application.properties in their jar:

spring.config.import=classpath:extra.properties

Rather than trying to automatically deal with finding extra.properties by parsing the properties, we think it's probably better if the user provides explicit configuration to indicate that they want the file in their native image.

We could improve the ConfigDataNotFoundFailureAnalyzer to provide an additional hint if a resource is not found and the application is a native image.

Comment From: snicoll

I've pushed something on a branch b6e95a0 but my main concern is that it is "impossible" to undo those defaults. I don't know how annoying that can be but it feels wrong users can't be in control of what gets shipped.

Comment From: sdeleuze

In practice, I don't think that will be too annoying, the impact on footprint will be minimal and that only makes the native behavior closer to the JVM one, so I think that's ok-ish at least for now.

Comment From: Nexyll

Customizing the default behavior could be valuable for the following reasons:

When building a JAR, it is possible to exclude all YAML configuration files from the JAR, which is not currently the case for native images with the existing approach.

This can be particularly useful in scenarios where you want to ensure that the application has no embedded default configurations, and that all necessary configurations are provided exclusively by the deployment environment.