Maven 依赖调解源码解析(七):总结

本文是系列文章《Maven 源码解析:依赖调解是如何实现的?》第七篇,也是最后一篇,主要做个总结。请按顺序阅读其他系列文章,系列文章总目录参见:hhttps://www.cnblogs.com/xiaoxi666/p/15583241.html。

 

总结

在本系列文章中,我们搭建了一个简单的多模块项目,以实验的形式,从源码角度解析了四种依赖调节原则。涉及到了传递依赖的两种调解原则、一种同文件内的覆盖原则,以及 dependencyManagement 依赖锁定原则。其中,传递依赖的两种调解原则涉及到 NearestConflictResolver 冲突调解器;而同文件内的覆盖原则最简单,就是简单的 Map 覆盖;最后,dependencyManagement 依赖锁定原则稍有些复杂,因为它涉及到了 dependencyManagement 的版本解析,并以解析出来的版本号为准。

在现实工作中,这几种依赖关系可能同时存在。尤其在大型工程中,dependencyManagement 版本锁定运用非常广泛,如果能从源码角度掌握其运行原理,一定会提升你对 Maven 的运用能力。

资源

本文中用到的源码已上传至 Github,地址:https://github.com/xiaoxi666/mavenDependencyDemo,需要的小伙伴请自行下载。

 

在阅读源码的过程中,我们学到了什么?

首先,我们了解了 Maven 依赖调解实现原理,以后面对各种输出信息,能够做到心中有数。稍微拓展一下,各种依赖管理工具的核心原理其实都差不多,无非就是管理各种依赖版本。希望本文能为你理解包管理工具的实现思路提供些许参考。

其次是设计方面的考量。Maven 提供了核心实现,并且预留了各种扩展点,可以让不同的插件实现不同的功能。这种开发模式可以非常方便功能扩展,对于一款软件的成长是很有利的。业界也有很多采用这种思路开发的产品,比如你熟悉的 Atom。

再说说算法,其实就是很经典的递归算法,以及常提到的备忘录(Map 存储已经解析过的依赖)。

最后,谈谈设计模式的体现。上面提到的源码就有几种,比如模板模式(不同冲突调解器的实现)、访问者模式(参照 visit 方法)、观察者模式(各种 Listener,事件产生时打印一些信息),以及桥接模式(dependency:tree 的实现其实是一个桥,类似于 slf4j 的模式)等等。

当然,你还学会了一种简单方便的 Maven 源码调试方法,哈哈。

 

参考

《Maven 实战》

Maven 官网:https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

你可能感兴趣的