== spring.config.import: which document wins? ==

application-import.yaml imports imported.yaml. Both set demo.greeting.
$ java -jar target/profiles-and-config-1.0.0.jar --spring.profiles.active=import

  active profiles : import
  effective value : from-imported-yaml
    1. from-imported-yaml                 <- 'file imported.yaml' via location 'optional:classpath:/imported.yaml''}
    2. from-application-import-yaml       <- 'file application-import.yaml' via location 'optional:classpath:/''}
    3. from-application-yaml              <- 'file application.yaml' via location 'optional:classpath:/''}
  holders that lost: 2

  demo.imported-only = yes-this-file-was-read

The imported file WON. spring.config.import does not behave like #include, and it
does not behave like a default either: the imported document is processed AFTER the
document that declared the import, so it outranks the file that pulled it in.
If you import a shared baseline expecting your own file to override it, every key
the baseline sets will quietly beat yours.

== one file, several documents, activated by condition ==
--- spring.profiles.active=<none> (with the multidoc profile) ---
  active profiles : multidoc
  effective value : from-multidoc-default-document
    1. from-multidoc-default-document     <- 'file application-multidoc.yaml' via location 'optional:classpath:/' (document ...
    2. from-application-yaml              <- 'file application.yaml' via location 'optional:classpath:/''}
  holders that lost: 1

--- spring.profiles.active=staging (with the multidoc profile) ---
  active profiles : multidoc, staging
  effective value : from-multidoc-staging-document
    1. from-multidoc-staging-document     <- 'file application-multidoc.yaml' via location 'optional:classpath:/' (document ...
    2. from-multidoc-default-document     <- 'file application-multidoc.yaml' via location 'optional:classpath:/' (document ...
    3. from-application-yaml              <- 'file application.yaml' via location 'optional:classpath:/''}
  holders that lost: 2

--- spring.profiles.active=prod (with the multidoc profile) ---
  active profiles : multidoc, prod, prod-db, prod-metrics
  effective value : from-application-prod-yaml
    1. from-application-prod-yaml         <- 'file application-prod.yaml' via location 'optional:classpath:/''}
    2. from-multidoc-prod-document        <- 'file application-multidoc.yaml' via location 'optional:classpath:/' (document ...
    3. from-multidoc-default-document     <- 'file application-multidoc.yaml' via location 'optional:classpath:/' (document ...
    4. from-application-yaml              <- 'file application.yaml' via location 'optional:classpath:/''}
  holders that lost: 3

Later documents in the same file win over earlier ones, so the unconditional first
document acts as the default and each conditional document overrides it.

== the activation Spring Boot refuses ==
application-badactivation.yaml tries to set spring.profiles.active from a document
that is itself conditional on a profile.
$ java -jar target/profiles-and-config-1.0.0.jar --spring.profiles.active=badactivation,staging

org.springframework.boot.context.config.InvalidConfigDataPropertyException: Property 
'spring.profiles.active' imported from location 'class path resource 
[application-badactivation.yaml]' is invalid in a profile specific resource [origin: class path 
resource [application-badactivation.yaml] from profiles-and-config-1.0.0.jar - 12:13]
	at 
org.springframework.boot.context.config.InvalidConfigDataPropertyException.lambda$throwIfPropert
yFound$1(InvalidConfigDataPropertyException.java:123)