本来想写一篇《如何自定义SpringBootStarter》的，但是为了更好的理解Starter的一些设计理念和要点，我提前提取了一些细节，在Mavenpom.xml中进行了解释，大家会经常看到dependencies中类似如下代码：true这里的true是什么意思？optional关键字的奥秘是一个古老的规则。画图说明问题：因为项目C使用了项目A（OptionalFeatureAClass）和项目B（OptionalFeatureBClass）的两个类。如果项目C不依赖packageA和packageB，那么编译就会失败。项目D依赖于项目C，但是对于项目D来说，class(OptionalFeatureAClass)和class(OptionalFeatureBClass)是可选的特性，所以为了让最终的war/ejb包不包含不必要的依赖，使用来声明当前的Dependency是可选的，默认不会被其他项目继承（像Java中的final类，不能被其他类继承）。如果项目D真的需要在项目C中使用OptionalFeatureAClass怎么办？那么我们需要在项目D的pom.xml中显式添加声明项目A的依赖，继续看下图：项目D需要使用项目A的OptionalFeatureAClass，那么就需要在ProjectD的pom.xml文件中显式添加对ProjectA的依赖。这也很好理解为什么Maven设计了optional关键字。假设一个关于数据库持久化的项目（ProjectC），为了适应更多类型的数据库持久化设计，比如Mysql持久化设计（ProjectA）和Oracle持久化设计（ProjectB），当我们的项目（ProjectD）使用ProjectC的持久化设计，不可能同时引入mysql驱动和oracle驱动，所以要显式指定一个，就是这个道理。实际情况下，在spring-boot-actuatorpom.xml文件中，有20多个依赖是可选的，因为SpringBoot不会将不需要的依赖也打包到你最终的jar包中，所以项目最终生成的jar包使用springbootactuator不会包含这20多个依赖的jar。如果您想使用哪一个，请指定将其添加到您的项目中即可。下篇文章自定义SpringBootStarter也是这个攻略，因为starter中包含了其他项目的特定功能。类似于本文中ProjectC的作用。到这里你就明白了是optionalout的奥秘？反向应用如果C项目引入的依赖不加true，那么D项目需要依赖C项目，但是只使用A项目的类怎么办？Maven也有解决办法，使用exclusion关键字，不多说，最后一段代码就明白了：top.dayarch.demoProject-Ctop.dayarch.demoProject-B总结到这里，以后在设计功能依赖的时候，应该明白怎么设计依赖，我这里推荐使用可选形式，简单来说就是你设计的任何菜品都可以依赖，想吃什么菜品都可以“抱蔡明”。接下来，我们将模拟官方标准创建一个自定义启动器...博客访问恢复正常，欢迎交流
