详解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(发邮件时,请将#更换为@)进行举报,并提供相关证据,一经查实,本站将立刻删除涉嫌侵权内容。