原文：https://blog.csdn.net/weixin_43888891/article/details/130510971
作者：怪 咖@
一、前言
<dependency> <groupId>cn.hutool</groupId> <artifactId>hutool-all</artifactId> <version>5.8.18</version> <optional>true</optional> </dependency>
optional表示是否会传递依赖，有两个可填值（假如不声明optional标签，默认就是false）：
false: 传递依赖
true：不传递依赖
举例：A引用了B的依赖，而B又引用了C依赖。
假如B引用C依赖的时候没有设置optional，那么A是可以使用C依赖的。
假如B引用C依赖的时候将optional标签设置为了true，那么在A当中就无法使用C依赖相关的方法，并且A调用B依赖的方法，而B依赖方法使用到了C，这时候会报找不到C依赖下的类，因为C不参与A的打包。
二、依赖传递代码演示
（1）如下是一个父子聚合工程，不设置optional的情况：
打成jar包后，我们可以将jar解压，解压后在BOOT-INF的lib下存放着所能使用的依赖jar包，在这里可以看到hutool。
（2）设置optional为true的情况：
没有那也就意味着我再download工程不能访问hutool的类了，想要访问只能在当前项目再次引用了。
（3）我有点好奇，既然这里看不到那么他究竟会参与打包吗？假如不参与打包，我们download工程调用common中的方法，然后common中的方法又使用了hutool工具类，那能否访问成功？接下来我们来一点一点的印证！
设置为true的时候是否会参与download工程的打包？
答：他是不会参与download的打包的，打成jar包后，我们可以将jar解压，解压后在BOOT-INF的lib下存放着所能使用的依赖jar包。
假如不参与打包，我们download工程调用common中的方法，然后common中的方法又使用了hutool工具类，那能否访问成功？
答：不能访问成功，直接会报找不到hutool的类
我解压common包发现连BOOT-INF都没有，并不是只有common的jar包解压没有，而是所有的都没有。
我一直以为common包引用了hutool，那么解压common包就应该在BOOT-INF下的jar中看到hutool.jar，其实不是的，maven打包会将所有依赖关系全部放到当前项目的BOOT-INF/jar目录下。
为此我专门在common当中写了一个方法，然后使用到了hutool当中的类。
然后我又在download工程下写了一个接口，让这个接口访问common包下test方法。
紧接着启动项目，启动download项目并没有异常，只要访问common包当中方法带有hutool相关的都报异常，说找不到hutool的包。因为我们刚刚也看过了，确实是没有这个jar包。
从而也证明了，不管是当前项目引用的，还是间接引用的，jar包都存放在BOOT-INF下/jar目录下，只要这下面没有jar，那当前项目就不能用。
三、为啥common的jar包下没有BOOT-INF呢？
在download下的BOOT-INF/lib下的common包解压后没有BOOT-INF我可以理解，因为所有的jar包都没有。但是为什么target当中的jar包解压后也没有，而download却有。他两个唯一的区别就是，一个是有main函数的web工程，一个是连main方法都没有的而且也没有打包插件。
我的父工程继承了spring-boot-starter-parent
而spring-boot-starter-parent当中对打包插件做了如下配置，也就意味着子工程一旦声明该插件就会遵循如下配置：
于是我在common包下添加了打包插件。注意使用打包插件意味着打出来的jar是一个可以直接执行的jar，因此必须要声明main函数，否则会打包异常的。
并且新增了一个主函数
于是再次打包，这时候会发现jar包大小已经发生了变化。解压后会发现他已经存在BOOT-INF了。
但是诡异的一幕发生了，download引入了common包，并且download调用了common包下的方法，直接就mvn install 不通过了。说在仓库找不到包。
但是在仓库当中实际上是存在这个包的。那也就是证明项目不能引用可执行jar。
于是我又把common的打包插件给去掉之后mvn install可以成功了。因此也证明了假如我们要封装自己的jar，一定不要使用打包插件。一旦使用插件就会变成了可执行jar，可执行jar是不可以被别的项目所引用的。
四、是否会影响父子工程之间的依赖继承呢？
假如我在聚合工程的父pom依赖当中使用optional为true，那子工程会继承吗？接下来进行演示。
注：在父工程设置optional为true，并不会影响子工程继承该依赖。
五、总结
将依赖设置为true不仅代表着依赖不会传递，就连打包的时候都不会将该jar打包进去，一旦使用到调用该jar包的方法就会异常。
在父工程设置optional为true，并不会影响子工程继承该依赖。
不管是当前项目引用的，还是间接引用的，所有依赖jar包都存放在jar解压后的BOOT-INF下/jar目录下，只要这下面没有jar，那当前项目就不能用。
什么时候将optional设置为true？
就拿hutool工具类来说，如下图：你想用他的某些工具类，他还让你引用一些第三方的依赖，为什么他不直接引用到自己的项目？
实际上hutool他肯定是引用了的，如果不引用他的项目可能连编译都编译不过，更别提打包给我们用了，他是将这个依赖设置为了true，假如谁用到了这块的功能，谁自己引入这个依赖。这样可以规避掉一些没有用到这块功能但是却引入了没有用的jar包。
