相信很多人都使用過 start.spring.io 來初始化自己的 Spring Boot 工程，這個工具為開發者提供了豐富的可選組件，並且可以選擇多種打包方式，大大方便了開發人員的使用。最近，阿里的 Nacos、Sentinel 也進入 start.spring.io 的選項中，進一步的方便開發者使用阿里雲的產品。
但是，生成的工程骨架中，只有組件座標信息，缺少對應的使用方法和 Demo 代碼；於是，開發者還是需要去尋找相關使用教程，或者樣例代碼；如果找的不對，或者是版本不匹匹配，還需要花費不少時間去排查和解決問題；這些問題都在無形中增加用戶的工作量。
我們將對軟件工程的抽象層次自上而下進行切分，會得到如下的幾個層級：行業、解決方案、應用、功能、組件；明顯的， start.spring.io 目前只能提供組件級別的支持。再將組件這層展開，會發現這樣一個生命週期：組件引入、組件配置、功能開發、線上運維。start.spring.io 也只實現了“組件引入”這一功能。
我們的目標是“讓阿里雲成為廣大 Java 開發者最好用的雲”。要實現這個目標，是否可以再向前走幾步，在解決“組件引入”問題的基礎上，將組件的典型使用方法、樣例代碼、使用說明也加入到工程中呢？
基於這種思考，我們上線了自己的 bootstrap 站點 start.aliyun.com ：
https://start.aliyun.com/
當然，本著不重複造輪子的原則，我們不再構建一套工程生成底層框架，而是使用 Spring Initializr 來實現這部分功能。在此之上專注於增加新特性，實現服務廣大開發者的目標。
Spring Initializr：https://github.com/spring-io/initializr
在 start.aliyun.com 中，我們為廣大開發者帶來了如下便利特性：
為每個組件提供了單獨的 DemoCode 和對應的配置樣例（本次已發佈）；
工程內置說明，減少用戶查找文檔的困難（部分實現）；
開發者只需要做減法，而非加法的使用方式（部分實現）；
提供多組件集成的解決方案（開發中）；
定期跟進 start.spring.io 的更新，方便大家使用到 spring 的最新功能。
start.aliyun.com：https://start.aliyun.com/
未來，我們還需要再助力開發者這條路上繼續發力，不僅僅是做好組件集成的工作，還要需要繼續向上支持，提供更多功能、服務、應用層級的快速構建能力。
本文，圍繞 spring initializr 框架，以 start.spring.io 為例，全面的給大家介紹如何使用和擴展這個框架，以及背後的運行原理。
使用篇
由於 spring-initializr 提供了靈活的擴展能力，以及豐富的默認實現；其使用方式也是非常的靈活多變；為了便於說明，我們直接通過 start.spring.io ，看看 Spring 自己是怎麼使用這套框架的。
1. 基本用法
基本用法的原則，是儘量少寫代碼，甚至是不寫代碼。只通過配置就可以實現 initializr 工程的創建。
依賴引入
要使用 spring-initializr ，首先要引入這套框架。很簡單，直接依賴 bom 即可：
io.spring.initializrinitializr-bom0.9.0.BUILD-SNAPSHOTpomimport
有了這個 bom 依賴，我們就不用再關心內部組件的版本等信息了。
一般來說，我們還需要引入具體組件：
io.spring.initializrinitializr-generator-springio.spring.initializrinitializr-version-resolverio.spring.initializrinitializr-web
具體每個子模塊的用途，這裡列出來，供讀者參考：
initializr-actuator: 監控診斷的附加信息，這個暫時忽略；
initializr-bom: 便於外部使用的bom依賴；
initializr-docs: 使用文檔；
initializr-generator: 核心工程生成庫；
initializr-generator-spring: 用於生成典型的spring boot工程；
initializr-generator-test: 測試框架；
initializr-metadata: 項目各個方面的元數據基礎結構；
initializr-service-sample: 基本使用案例；
initializr-version-resolver:版本號解析能力；
initializr-web: 提供給三方客戶端使用的web入口。
基本配置
完成了框架引入，就需要做一些基礎配置了支持哪些語言：Java、groovy、Kotlin支持哪些版本：1.8、11、13支持哪些打包方式：jar、war
將這些信息全部配置到 application.yml 文件中，如下：
完成了框架引入，就需要做一些基礎配置了
支持哪些語言：Java、groovy、Kotlin
支持哪些版本：1.8、11、13
支持哪些打包方式：jar、war
initializr: packagings: - name: Jar id: jar default: true - name: War id: war default: false javaVersions: - id: 13 default: false - id: 11 default: false - id: 1.8 name: 8 default: true languages: - name: Java id: java default: true - name: Kotlin id: kotlin default: false - name: Groovy id: groovy default: false
其中 name 是可選的， id 是必填的。
每個配置項下，可以有一個默認值（將 default 這是為 true 即可），除了這些基本配置，我們還需要定義可以支持的項目類型：
initializr: types: - name: Maven Project id: maven-project description: Generate a Maven based project archive. tags: build: maven format: project default: true action: /starter.zip - name: Maven POM id: maven-build description: Generate a Maven pom.xml. tags: build: maven format: build default: false action: /pom.xml - name: Gradle Project id: gradle-project description: Generate a Gradle based project archive. tags: build: gradle format: project default: false action: /starter.zip - name: Gradle Config id: gradle-build description: Generate a Gradle build file. tags: build: gradle format: build default: false action: /build.gradle
默認情況下， initializr 已經支持 4 種項目類型：
/pom.xml 生成一個 Maven 的 pom.xml 配置文件
/build.gradle 生成 Gradle 的配置文件
/starter.zip 生成 zip 方式壓縮的工程文件
/starter.tgz 生成以 tgz 方式壓縮的工程文件
通過 tags 標籤，我們可以定義不同配型的編譯方式 (build) 和打包格式（format）。
配置基本依賴
完成了基本配置以後，就可以配置可選的依賴組件了。
依賴配置以 dependency 為 key ，同樣配置在 application.yml 的 initializr 下面，這裡給出一個簡單的樣例：
initializr: dependencies: - name: Web content: - name: Web id: web description: Full-stack web development with Tomcat and Spring MVC - name: Developer Tools content: - name: Spring Boot DevTools id: devtools groupId: org.springframework.boot artifactId: spring-boot-devtools description: Provides fast application restarts, LiveReload, and configurations for enhanced development experience. - name: Lombok id: lombok groupId: org.projectlombok artifactId: lombok description: Java annotation library which helps to reduce boilerplate code.
dependencies 下定義分組。分組的作用是便於展示和快速查找，所以不需要 id ，只需要 name 信息；每個分組的 content 是分組的具體內容，也就是這個分組下的組件定義；支持以列表形式定義多個；另外，每個分組都可以設置當前分組內組件公用的配置信息。
每一依賴，包含如下的基本信息：
id：組件的唯一標識符
groupId & artifactId：組件的座標
name：顯示名稱
description：描述信息，主要用於展示用途
version：組件版本
關於 groupId & artifactId：如果設置了座標，生成的項目裡會使用這裡的座標定位組件；但是如果沒有設置座標，框架會認為這是一個標準的 spring-boot 組件，自動添加 spring-boot-starter-{id} 作為生成的依賴座標。
關於 version：如果直接在組件上設置版本信息，框架會直接使用這個值作為組件依賴的版本；但是很多時候，組件的版本會受到 spring-boot 版本的影響，此時就需要對版本做特殊的定義 & 管理。
配置依賴版本管理
這裡需要先了解一下版本命名規則：一個典型的版本，一般包含如下 4 個信息：大版本、小版本、修正版本、版本限定符。
版本範圍有一個上界和下界，可以方括號 [] 或者圓括號 () 表示。方括號代表上下界的閉區間，圓括號代表上下界的開區間。
例如：“[1.1.6.RELEASE,1.3.0.M1)”代表所有從 1.1.6.RELEASE 到 1.3.0.M1 之間所有的版本（包含 1.1.6.RELEASE ，但不包含 1.3.0.M1 ）。
同時，可以使用單一版本號作為版本範圍，例如 “1.2.0.RELEASE”。單一版本號的版本範圍代表“從這個版本以及之後的所有版本”。
如果需要使用“最新的 Release 版本”的概念，可以使用一個字母 x 代表具體的版本號。
例如， 1.4.x.BUILD-SNAPSHOT 代表 1.4.x 的最新快照版本。
再比如：如果需要表達，從 1.1.0.RELEASE 到 1.3.x 之間的所有版本，可以用[1.1.0.RELEASE,1.3.x.RELEASE]來表達。
另外，版本限定符也是有順序的（升序）：
M：里程碑版本
RC：發佈候選版本
RELEASE：發佈版本
BUILD-SNAPSHOT：為開發構建的快照版本
所以快照版本是所有限定符裡優先級最高的。假設某個組件需要 Spring Boot 的最新版本，可以使用 1.5.x.BUILD-SNAPSHOT (假設 1.5 版是 Spring Boot 的最新版本)。
最後，版本範圍中討論的版本，指的都是 Spring Boot的版本，而不是組件自己的版本。
前面介紹了，可以使用 version 屬性定義組件的具體版本號；但是，如果組件版本與Spring Boot 的版本存在關聯關係，就需要使用 compatibilityRange 來配置依賴的版本範圍。
compatibilityRange 可以定義在兩個地方：
直接定義在組件（或 Bom ）上
這種定義方式，代表組件只支持 Spring Boot 的某一個版本範圍，例如下面的配置：
initializr: dependencies: - name: Stuff content: - name: Foo id: foo ... compatibilityRange: 1.2.0.M1 - name: Bar id: bar ... compatibilityRange: "[1.5.0.RC1,2.0.0.M1)"
Foo 可以支持 Spring boot 1.2.0 之後的所有版本；而Bar只能支持 Spring Boot 1.5.0 到 2.0.0 之間的版本，且不包含 2.0.0 ；
定義在組件的 mappgin 屬性下
可以支持在 Spring Boot 不同版本之下對組件做不同的設置（可以重置組件部分或者是所有的屬性），下面的例子中對 artifactId 做了特殊定義：
initializr: dependencies: - name: Stuff content: - name: Foo id: foo groupId: org.acme.foo artifactId: foo-spring-boot-starter compatibilityRange: 1.3.0.RELEASE mappings: - compatibilityRange: "[1.3.0.RELEASE,1.3.x.RELEASE]" artifactId: foo-starter - compatibilityRange: "1.4.0.RELEASE"
這個例子中， foo 在 Spring Boot 的 1.3 使用 foo-starter 作為座標的 artifactId ；在 1.4.0.RELEASE 以及之後的版本中，還是使用 foo-spring-boot-starter 作為 artifactId 的值；
使用 Bom 管理版本：有時候，需要使用 Bom 的方式管理組件版本；此時不需要對組件單獨設置版本號。
要使用 Bom ，首先要配置 Bom 定義：
initializr: env: boms: my-api-bom: groupId: org.acme artifactId: my-api-dependencies version: 1.0.0.RELEASE repositories: my-api-repo-1
注意：Bom 信息，定義在 initializr.env.boms下面。
其屬性和依賴組件基本一致，都是座標、版本；同時， Bom 也支持版本範圍管理。
完成了 Bom 的定義，就需要在組件中引用 Bom ：
initializr: dependencies: - name: Other content: - name: My API id : my-api groupId: org.acme artifactId: my-api bom: my-api-bom
一旦用戶選擇了 my-api 組件，框架會自動為生成的項目添加了 my-api-dependencies 的 Bom 依賴；
2. 高級定製
啟用緩存
如果你啟動過 start.spring.io 項目，你會在日誌裡發現這樣的輸出 “Fetching boot metadata from spring.io/project_metadata/spring-boot” 為了避免過於頻繁的檢查 Spring Boot 版本，官方是建議配合緩存一起使用。
首先需要引入緩存框架：
javax.cachecache-apiorg.ehcacheehcache
然後，在 SpringBootApplication 類上增加 @EnableCaching 註解:
如果需要自己定義緩存，可以調整如下緩存配置：
增加 Demo代碼：由於不同的組件有不同的功能，如果需要為項目增加 Demo 代碼。
為不同的組件增加獨立配置：還記得原理篇中提到的 spring.factories 嗎？對，我們要增加自己的配置項，就需要在這裡增加針對不同組件樣例代碼的擴展入口。
io.spring.initializr.generator.project.ProjectGenerationConfiguration=
com.alibaba.alicloud.initializr.extension.dependency.springboot.SpringCloudProjectGenerationConfiguration
在 SpringCloudProjectGenerationConfiguration 中，我們通過 ConditionalOnRequestedDependency 註解來識別不同組件：
@ProjectGenerationConfiguration public class SpringCloudAlibabaProjectGenerationConfiguration { private final InitializrMetadata metadata; private final ProjectDescription description; private final IndentingWriterFactory indentingWriterFactory; private final TemplateRenderer templateRenderer; public SpringCloudAlibabaProjectGenerationConfiguration(InitializrMetadata metadata, ProjectDescription description, IndentingWriterFactory indentingWriterFactory, TemplateRenderer templateRenderer) { this.metadata = metadata; this.description = description; this.indentingWriterFactory = indentingWriterFactory; this.templateRenderer = templateRenderer; } @Bean @ConditionalOnRequestedDependency("sca-oss") public OSSDemoCodeContributor ossContributor() { return new OSSDemoCodeContributor(description, templateRenderer); } ...... }
上面的代碼，會在選擇了 sca-oss 組件時，創建一個 OSSDemoCodeContributor 用於對應 Demo 代碼的生成。
生成具體的 Demo 代碼：繼續以 OSSDemoCodeContributor 為例，它是一個 ProjectContributor ，會在項目文件空間創建完成了調用。我們需要為這個 Contributor 在實例化時增加生成過程中需要的元數據信息，例如 ProjectDescription 。
代碼生成過程，比較簡單，可以直接複用框架中就提供的 mstache 模板引擎。
我們直接將 Demo 代碼，以模板的形式，放置在 resources 文件夾之下：
然後，我們再通過模板引擎，解析這些模板文件，再拷貝到項目目錄下即可：
private void writeCodeFile(TemplateRenderer templateRenderer, Language langeuage, Map
params, Path path, String temp) throws IOException { ...... Path pkgPath = 生成包路徑 Path filePath = 成成代碼文件路徑 // 渲染模板 String code = templateRenderer.render(temp, params); // demo 文件寫入 Files.createDirectories(pkgPath); Files.write(filePath, code.getBytes("UTF-8")); }
除了模板代碼以外，我們通常還需要在 applicatioin.properties 文件寫入模塊的配置信息。
這裡，我們依然可以使用代碼生成的方式：創建模板、解析模板，追加文件的方式來實現。具體代碼這裡就不貼了，讀者可以自己發揮。
原理篇
原理篇，主要介紹 spring.initializr 是如何實現項目工程構建的，以及作為一個框架，如何提供豐富的擴展能力的。
在原理篇，我們將 initializr 的執行分為兩個階段：啟動階段和生成階段。
啟動階段：啟動應用，加載配置，擴展信息初始化；
生成階段：一個項目生成，從收到請求，到返回內容的完整流程。
1. 啟動階段
再開始啟動流程之前，先要看一下 initializr 的擴展體系。
整個架構大量使用了 spring 的 spi 機制，我們來看一下一共有哪些 spring.factories ：
initializr-generator/src/main/resources/META-INF/spring.factories
initializr-generator-spring/src/main/resources/META-INF/spring.factories
initializr-web/src/main/resources/META-INF/spring.factories
initializr-actuator/src/main/resources/META-INF/spring.factories
start-site/src/main/resources/META-INF/spring.factories
其中只有一個在 start.spring.io 中，其他 4 個都在 initializr 工程中（各 spring.factories 的具體內容見參考資料）。
不過要注意，這些 spring.factories 定義，僅僅代表了各個 SPI 有哪些擴展。不同spi的實現創建和使用完全是在不同的階段進行的。
在應用啟動階段，其實只有一個 spi 會被加載（暫不考慮 actuator）：io.spring.initializr.web.autoconfigure.InitializrAutoConfiguration 。
@Configuration @EnableConfigurationProperties(InitializrProperties.class) public class InitializrAutoConfiguration { @Bean @ConditionalOnMissingBean public ProjectDirectoryFactory projectDirectoryFactory() @Bean @ConditionalOnMissingBean public IndentingWriterFactory indentingWriterFactory() @Bean @ConditionalOnMissingBean(TemplateRenderer.class) public MustacheTemplateRenderer templateRenderer(Environment environment, ObjectProvidercacheManager) @Bean @ConditionalOnMissingBean public InitializrMetadataUpdateStrategy initializrMetadataUpdateStrategy(RestTemplateBuilder restTemplateBuilder, ObjectMapper objectMapper) @Bean @ConditionalOnMissingBean(InitializrMetadataProvider.class) public InitializrMetadataProvider initializrMetadataProvider(InitializrProperties properties, InitializrMetadataUpdateStrategy initializrMetadataUpdateStrategy) @Bean @ConditionalOnMissingBean public DependencyMetadataProvider dependencyMetadataProvider() @Configuration @ConditionalOnWebApplication static class InitializrWebConfiguration { @Bean InitializrWebConfig initializrWebConfig() @Bean @ConditionalOnMissingBean ProjectGenerationControllerprojectGenerationController( InitializrMetadataProvider metadataProvider, ApplicationContext applicationContext) @Bean @ConditionalOnMissingBean ProjectMetadataController projectMetadataController(InitializrMetadataProvider metadataProvider, DependencyMetadataProvider dependencyMetadataProvider) @Bean @ConditionalOnMissingBean CommandLineMetadataController commandLineMetadataController(InitializrMetadataProvider metadataProvider, TemplateRenderer templateRenderer) @Bean @ConditionalOnMissingBean SpringCliDistributionController cliDistributionController(InitializrMetadataProvider metadataProvider) } }
這裡會做如下幾件事情：
初始化元數據 Provider
創建模板引擎
創建目錄、縮進工廠
初始化 web 配置
創建 spring mvc 的 web 入口
各種 ProjectGenerationController
其中最關鍵的元數據加載部分，使用了 EnableConfigurationProperties 註解，將 spring 環境中的配置項寫到 InitializrProperties 上：
在 application.yml 文件中，可以找到如下的配置信息，這裡就是實際的項目依賴關係元數據的配置存儲點：
2. 生成階段
生成階段，spring-initializr 使用了一個很有意思的實現方式：initializr 框架會為每一次項目生成，創建一個獨立的 context 用於存放生成流程中需要使用到的各種 bean 。
先來一張時序圖：
藍色的類，是在應用啟動階段就完成了創建和數據填充；其生命週期和整個應用一致；黃色的類，會在具體的項目構建過程中生成；其生命週期在一次項目生成流程之內結束。
從上面的時序圖中可以看出：一個典型的創建行為，通常從 ProjectGenerationController收到web端的創建請求開始，通過 ProjectGenerationInvoker 這個中間層轉換，最終進入 ProjectGenerator 的核心構建流程。
主幹流程
下圖，是 ProjectGenerator 的核心構建流程：
106 行，通過 contextFactory 構建了一個新的 ProjectGenerationContext 。
看一下這個context的繼承關係，原來於spring提供的AnnotationConfigApplicationContext 。
再結合 110 行的 refresh() 方法，是不是發現了什麼？就是 spring 的 ApplicationContext 的刷新流程。
107 行的 resolve 方法，向 context 中註冊了一個 ProjectDescription的Provider，代碼如下：
由於註冊的是 Provider ，所以這段邏輯會在 Context 執行 refresh 時運行。
這裡的 ProjectDescriptionCustomizer 就是針對 ProjectDescription 的擴展，用於對用戶傳入的 ProjectDescription 做調整。這裡主要是一些強制依賴關係的調整，例如語言版本等。
這時候再看 108 行，這裡向 Context 註冊一個 Configuration 。
那麼這個 Configuration 包含了什麼內容呢？一起來看下面這段代碼：
ProjectGenerationConfiguration！！！前面提到的 spring.factories 中有很多這個 SPI 的實現（參見參考資料）。
原來，initializr 的整個擴展體系，在這裡才開始創建實例；
ProjectGenerator 的 109 行，對一個 consumer 做了 accept 操作；其實就是調用了下面的代碼：
這裡通過 setParent 將應用的主上下文設置為這次 ProjectGenerationContext 的父節點。
並且向這次 ProjectGenerationContext 中註冊了元數據對象。
最後，在 ProjectGenerator 的 112 行，調用了 projectAssetGenerator 的 generate 方法，實現如下：
通過上面的代碼可以發現，這裡對實際的工程構建工作，其實就是很多的 ProjectContributor 共同疊加；
至此，主幹流程已經結束了。
我們可以發現，在主幹流程中，沒有做任何寫文件的操作（只創建了根文件夾）；它僅僅是定義了一套數據加載、擴展加載的機制與流程，將所有的具體實現都作為擴展的一部分。
擴展流程
spring-initializr 提供了 2 種主要擴展途徑：ProjectContributor 和 xxxxxCustomizer。
從方法簽名就可以看出，入參只有一個項目的根路徑，其職責就是向這個路徑下些人項目文件。這個擴展點非常的靈活，幾乎可以支持任何的代碼、配置文件寫入工作。
實現過程中，可以通過 ProjectGenerationContext 獲取相關依賴，然後通過自定義邏輯完成文件生成工作。
下面是 initializr 和 start.spring.io 提供的 ProjectContributor 實現：
拿幾個主要的實現看看：
MavenBuildProjectContributor：寫入 maven 項目 pom.xml 文件；
WebFoldersContributor：創建 web 項目的資源文件夾；
ApplicationPropertiesContributor：寫入 application.properties 文件；
MainSourceCodeProjectContributor：寫入應用入口類 xxxApplication.java 文件；
HelpDocumentProjectContributor：寫入幫助文檔 HELP.md 文件。
相對於 ProjectContributor，xxxxxCustomizer 不是一個統一的接口，我把他理解為一種感念和與之對應的命名習慣；每個 Customizer 都有自己明確的名字，同時也對應了明確的觸發邏輯和職責邊界。
下面列出框架提供的 Customizer 的說明：
MainApplicationTypeCustomizer：自定義 MainApplication 類；
MainCompilationUnitCustomizer：自定義 MainApplication 編譯單元；
MainSourceCodeCustomizer：自定義 MainApplication 源碼；
BuildCustomizer：自定義項目構建工具的配置內容；
GitIgnoreCustomizer：自定義項目的 .gitignore 文件；
HelpDocumentCustomizer：自定義項目的幫助文檔；
InitializrMetadataCustomizer：自定義項目初始化配置元數據；這個 Customizer 比較特殊，框架會在首次加載元數據配置時調用；
ProjectDescriptionCustomizer：自定義 ProjectDescription ；即在生成項目文件之前，允許調整項目描述信息；
ServletInitializerCustomizer：自定義 web 應用在類上的配置內容；
TestApplicationTypeCustomizer：自定義測試 Application 類；
TestSourceCodeCustomizer：自定義測試 Application 類的源碼。
參考資料
1. 相關鏈接initializr 說明文檔
https://docs.spring.io/initializr/docs/current-SNAPSHOT/reference/html/
spring-initializr 項目地址
https://github.com/spring-io/initializr
start.spring.io 項目地址
https://github.com/spring-io/start.spring.io
2. spring.factories 明細
initializr-generator/src/main/resources/META-INF/spring.factoriesio.spring.initializr.generator.buildsystem.BuildSystemFactory= io.spring.initializr.generator.buildsystem.gradle.GradleBuildSystemFactory, io.spring.initializr.generator.buildsystem.maven.MavenBuildSystemFactory io.spring.initializr.generator.language.LanguageFactory= io.spring.initializr.generator.language.groovy.GroovyLanguageFactory, io.spring.initializr.generator.language.java.JavaLanguageFactory, io.spring.initializr.generator.language.kotlin.KotlinLanguageFactory io.spring.initializr.generator.packaging.PackagingFactory= io.spring.initializr.generator.packaging.jar.JarPackagingFactory, io.spring.initializr.generator.packaging.war.WarPackagingFactory
initializr-generator-spring/src/main/resources/META-INF/spring.factories：
io.spring.initializr.generator.project.ProjectGenerationConfiguration= io.spring.initializr.generator.spring.build.BuildProjectGenerationConfiguration, io.spring.initializr.generator.spring.build.gradle.GradleProjectGenerationConfiguration, io.spring.initializr.generator.spring.build.maven.MavenProjectGenerationConfiguration, io.spring.initializr.generator.spring.code.SourceCodeProjectGenerationConfiguration, io.spring.initializr.generator.spring.code.groovy.GroovyProjectGenerationConfiguration, io.spring.initializr.generator.spring.code.java.JavaProjectGenerationConfiguration, io.spring.initializr.generator.spring.code.kotlin.KotlinProjectGenerationConfiguration, io.spring.initializr.generator.spring.configuration.ApplicationConfigurationProjectGenerationConfiguration, io.spring.initializr.generator.spring.documentation.HelpDocumentProjectGenerationConfiguration, io.spring.initializr.generator.spring.scm.git.GitProjectGenerationConfiguration
initializr-web/src/main/resources/META-INF/spring.factories：
org.springframework.boot.autoconfigure.EnableAutoConfiguration= io.spring.initializr.web.autoconfigure.InitializrAutoConfiguration org.springframework.boot.env.EnvironmentPostProcessor= io.spring.initializr.web.autoconfigure.CloudfoundryEnvironmentPostProcessor
initializr-actuator/src/main/resources/META-INF/spring.factories：
org.springframework.boot.autoconfigure.EnableAutoConfiguration= io.spring.initializr.actuate.autoconfigure.InitializrActuatorEndpointsAutoConfiguration, io.spring.initializr.actuate.autoconfigure.InitializrStatsAutoConfiguration
start-site/src/main/resources/META-INF/spring.factories：
io.spring.initializr.generator.project.ProjectGenerationConfiguration= io.spring.start.site.extension.build.gradle.GradleProjectGenerationConfiguration, io.spring.start.site.extension.build.maven.MavenProjectGenerationConfiguration, io.spring.start.site.extension.dependency.DependencyProjectGenerationConfiguration, io.spring.start.site.extension.dependency.springamqp.SpringAmqpProjectGenerationConfiguration, io.spring.start.site.extension.dependency.springboot.SpringBootProjectGenerationConfiguration, io.spring.start.site.extension.dependency.springcloud.SpringCloudProjectGenerationConfiguration, io.spring.start.site.extension.dependency.springdata.SpringDataProjectGenerationConfiguration, io.spring.start.site.extension.dependency.springintegration.SpringIntegrationProjectGenerationConfiguration, io.spring.start.site.extension.dependency.springrestdocs.SpringRestDocsProjectGenerationConfiguration, io.spring.start.site.extension.description.DescriptionProjectGenerationConfiguration, io.spring.start.site.extension.code.kotin.KotlinProjectGenerationConfiguration
