详解Maven optional关键字透彻图解
写在前面
本来想写一篇「如何自定义SpringBootStarter」，但是为了更好理解Starter的一些设计理念和其中的关键点，所以提前将一些细节内容单独提取出来讲解说明
在Mavenpom.xml中，你经常会看到依赖项中有类似下面的代码:
sample.ProjectA Project-A 1.0 compile true
这里的
optional关键字的奥秘
老规矩，画个图说明问题:
由于projectC使用到了两个来自projectA的类(OptionalFeatureAClass)和projectB的类(OptionalFeatureBClass).如果projectC没有依赖packageA和packageB，那么编译将会失败。
projectD依赖projectC，但是对于projectD来说，类(OptionalFeatureAClass)和类(OptionalFeatureBClass)是可选的特性，所以为了让最终的war/ejbpackage不包含不必要的依赖，使用
如果projectD确实需要用到projectC中的OptionalFeatureAClass怎么办呢？那我们就需要在projectD的pom.xml中显式的添加声明projectA依赖，继续看下图:
ProjectD需要用到ProjectA的OptionalFeatureAClass，那么需要在ProjectD的pom.xml文件中显式的添加对ProjectA的依赖
到这也就很好理解为什么Maven为什么要设计optional关键字了，假设一个关于数据库持久化的项目(ProjectC),为了适配更多类型的数据库持久化设计，比如Mysql持久化设计(ProjectA)和Oracle持久化设计(ProjectB)，当我们的项目(ProjectD)要用的ProjectC的持久化设计，不可能既引入mysql驱动又引入oracle驱动吧，所以我们要显式的指定一个，就是这个道理了
实际案例
在spring-boot-actuatorpom.xml文件中，有超过20个依赖是optional
因为SpringBoot不可能将没必要的依赖也打包到你最终的jarpackage中，所以用到springbootactuator的项目最终生成的jarpackage中不会包含这20多个依赖jar，如果你要用到哪一个，显式的加入到你的项目就好了
在接下来的文章，自定义SpringBootStarter也是这个策略，因为starter是包含特定功能为其他项目服务用的，类似本文的ProjectC的角色了，到这里你理解optional的奥秘了吗？
反向应用
如果ProjectC引入的依赖没有加
top.dayarch.demo Project-C top.dayarch.demo Project-B
总结
到这里，在你今后设计功能性依赖时，你应该明白怎样设计依赖关系了,我这里推荐使用optional的形式，简单来说，你设计的依赖什么菜都有，想吃什么菜自己"抱蔡明"就好，接下来我们就模拟官方标准创建自定义的starter......博客访问恢复正常，欢迎交流
灵魂追问
- 有很多童鞋项目组用的构建工具时Gradle，你知道Gradle中是怎样表示的吗？
- 自定义starter，你知道官方标准starter的结构是什么样的吗？
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持毛票票。
声明：本文内容来源于网络，版权归原作者所有，内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现有涉嫌版权的内容，欢迎发送邮件至：czq8825#qq.com（发邮件时，请将#更换为@）进行举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。