Dependency optimization in dubbo-cluster

[chaicho]

在dubbo-cluster模块中，类org/apache/dubbo/rpc/cluster/filter/support/ObservationSenderFilter.java中存在如下的import:

import io.micrometer.observation.Observation;
import io.micrometer.observation.ObservationRegistry;

而在它对应的pom.xml里，并没有声明io.micrometer:micrometer-observation，能正常编译主要因为micrometer-observation作为传递依赖被引入
org.apache.dubbo:dubbo-cluster:3.2.1
-> org.apache.dubbo:dubbo-metrics-registry:3.2.1::compile
-> org.apache.dubbo:dubbo-metrics-api:3.2.1::compile
-> io.micrometer:micrometer-core:1.10.6::compile
-> io.micrometer:micrometer-observation:1.10.6::compile

[songxiaosheng]

间接依赖有啥问题不

[chaicho]

tldr: 用间接依赖的话，maven不知道你用了micrometer-observation，也就影响了正常的依赖管理。

会导致依赖管理相关的问题，如果直接使用传递依赖而不声明它们，就相当于绕过了maven进行依赖管理。举个例子，
如果用户的项目A同时使用dubbo:3.2.1和io.micrometer:micrometer-core的1.0.0，那么当前的micrometer-core:1.10.6的依赖树就会因为maven的就近原则被隐蔽掉。

• 最坏的情况，如果micrometer-core:1.0.0里并没有将micrometer-observation作为依赖，那么dubbo-cluster就没法被正常编译运行，因为它使用的micrometer-observation已经随着micro-core:1.10.6的依赖树被隐去了，因为没有声明，maven也不会知道你需要这个包。
• 即使它包含了micrometer-observation作依赖，但observation的版本并不是当前所依赖的版本，且maven也不知道你在dubbo-cluster里用了它，如果两个版本micrometer-observation的特性的差距导致了运行时问题，也就没法被maven发现。

所以最好将项目中直接使用到的依赖都列在pom.xml里，而不是通过传递依赖使用，因为这样破坏了maven的依赖管理。

[songxiaosheng]

确实会有这个问题，不过Java的类加载是延迟加载的，如果是非内部核心类，比如扩展类型在使用到的时候才会去加载对应类型，这种也可以考虑放到到扩展包里，减少dubbo核心代码的第三方依赖数量

[chaicho]

我的理解是，不管是直接依赖还是传递依赖，都会被maven添加到classpath里， 供Java 类加载器在需要时从里面查找。直接声明依赖似乎并不会影响您提到的Java 类加载器的延迟加载。

在 dubbo-cluster 模块中，即使 io.micrometer:micrometer-observation 包没有被直接声明为依赖，由于dubbo-metrics-registry已经被声明在dubbo-cluster的pom.xml，所以maven仍然会将micrometer-observation作为传递依赖引入。唯一的区别就是此时maven无法知道dubbo-cluster自身也引入了micrometer-observation。

所以在pom.xml声明里所有的引入的依赖似乎并没有什么坏处，反而能避免直接使用传递依赖所造成的依赖管理方面的问题。如果我对您的观点理解有误，还麻烦您斧正。

[songxiaosheng]

我说的可能和你的不太一样，我意思是按需引入默认情况下类型不存在不影响使用的话就不引入这个依赖，减少核心依赖的大小与依赖冲突的风险，SpringBoot源码里面有很多飘红的类型比如kotlin不过不影响使用。你看看哪种比较好😄