Document configuration file format v2.3 in metadata

See gh-1697

Signed-off-by: sijun-yang <yangsijun5528@gmail.com>

Author: YangSiJun528

initializr-docs/src/main/asciidoc/configuration-guide.adoc

@@ -53,7 +53,7 @@ generate assets based on available candidates.
 A project is defined by `ProjectDescription` which consists of the following properties:
 
 * Basic coordinates such as `groupId`, `artifactId`, `name`, `description`
-* The `BuildSystem` and `Packaging`
+* The `BuildSystem`, `Packaging` and `ConfigurationFileFormat`
 * The JVM `Language`
 * The requested dependencies, indexed by ID
 * A platform `Version` used by the project. This can be used to tune available
@@ -341,6 +341,25 @@ NOTE: `Jar` and `War` packaging types are available out-of-the-box. For addition
 packaging formats, you need to implement the `Packaging` abstraction and provide a
 `PackagingFactory` that corresponds to it.
 
+Configuration file formats are configurable in the same way as above:
+
+[source,yaml,indent=0]
+----
+    initializr:
+      configuration-file-formats:
+        - name: Properties
+          id: properties
+          default: true
+        - name: YAML
+          id: yaml
+          default: false
+----
+
+NOTE: `Properties` and `YAML` configuration file formats are supported out-of-the-box.
+If you need to support additional configuration formats, you must implement the
+`ConfigurationFileFormat` abstraction and provide a `ConfigurationFileFormatFactory` that can
+generate it.
+
 
 
 [[create-instance-text-only-settings]]

initializr-docs/src/main/asciidoc/metadata-format.adoc

@@ -14,15 +14,16 @@ sent to the service. A good structure for a user agent is `clientId/clientVersio
 == Service Capabilities
 Any third party client can retrieve the capabilities of the service by issuing a
 `GET` on the root URL using the following `Accept` header:
-`application/vnd.initializr.v2.2+json`. Please note that the metadata may evolve in a
+`application/vnd.initializr.v2.3+json`. Please note that the metadata may evolve in a
 non backward compatible way in the future so adding this header ensures the service
 returns the metadata format you expect.
 
 The following versions are supported:
 
 * `v2` initial version, with support of V1 version format only
 * `v2.1` support compatibility range and dependencies links
-* `v2.2` (current) support for V1 and V2 version formats.
+* `v2.2` support for V1 and V2 version formats.
+* `v2.3` (current) support for selecting the configuration file format.
 
 This is an example output for a service running at `start.example.com`:
 
@@ -45,6 +46,8 @@ component responsible to generate the project (for instance, generate an executa
 _jar_ project).
 * Java version: the supported java versions
 * Language: the language to use (e.g. Java)
+* Configuration file format: the supported configuration formats for the generated
+project (e.g. `application.properties`, `application.yml`)
 * Boot version: the platform version to use
 * Additional basic information such as: `groupId`, `artifactId`,  `version`, `name`,
 `description` and `packageName`.
@@ -168,6 +171,14 @@ include::{snippets}/metadataWithCurrentAcceptHeader/response-fields/language.val
 
 
 
+=== Configuration file format
+The `configurationFileFormat` element provides a list of possible configuration file formats for the project:
+
+.Configuration file format example
+include::{snippets}/metadataWithCurrentAcceptHeader/response-fields/configurationFileFormat.values.0.adoc[]
+
+
+
 === Platform versions
 The `bootVersion` element provides the list of available platform versions