关于parquet-jackson shaded dummy模块的疑问及依赖树咨询

在Maven项目漏洞排查中发现，parquet-hadoop依赖的parquet-jackson是一个专门用于Shade Jackson构件的dummy模块。该模块内嵌的Jackson版本存在已知漏洞且已过时，Jfrog漏洞扫描工具可以检测到这个问题，但IntelliJ和Maven CLI生成的依赖树仅显示parquet-jackson模块本身，无法直接看到其内部包含的Shade版Jackson，给漏洞定位和排查带来了困难。

1. 为何设计parquet-jackson这个dummy模块，而非直接依赖Jackson？ #

parquet-jackson的核心作用是作为Parquet生态中Jackson依赖的统一入口：

• 它将Jackson的类进行Shade（重新打包并修改包名）后内嵌到自身jar中，对外以dummy模块的形式提供依赖，避免用户直接引入不同版本的Jackson引发冲突。
• Parquet的其他模块（如parquet-hadoop）只需要依赖这个统一模块，无需重复处理Shade逻辑，简化了Parquet内部的依赖管理。
• 这种设计让Parquet团队可以完全掌控内部使用的Jackson版本，不受外部项目依赖的Jackson版本影响。

2. Shade自身Jackson副本避免的副作用具体是什么？相比直接依赖有何优势？ #

避免的副作用 #

主要是依赖版本冲突和类加载问题：

• 如果直接依赖Jackson，当项目中其他组件引入了不同版本的Jackson时，可能出现类方法不兼容、序列化/反序列化行为不一致的问题，甚至触发NoClassDefFoundError或IllegalAccessError。
• 不同版本的Jackson类在类加载器中共存时，可能引发类版本冲突，导致Parquet的序列化逻辑异常。

优势 #

• 完全隔离：Parquet内部使用的Jackson是独立的副本，包名被修改（通常改为org.apache.parquet.shaded.com.fasterxml.jackson），不会与项目中其他依赖的Jackson类产生冲突。
• 兼容性强：无论项目本身使用Jackson 2.x的哪个版本，Parquet都能正常运行，无需担心版本适配问题。
• 可控性高：Parquet团队可以固定内部使用的Jackson版本，确保自身序列化逻辑的稳定性，不受外部依赖变更的影响。

3. 能否在IntelliJ或Maven CLI的依赖树中显示Shaded模块？ #

Maven依赖树和IntelliJ的依赖视图仅追踪模块级别的依赖关系，而Shade是将Jackson的类直接打包到parquet-jackson的jar文件中，这些类已经不属于原始的Jackson模块，因此无法直接在依赖树中显示。不过可以通过以下方式间接排查：

• Maven命令：使用jar tf parquet-jackson-<version>.jar查看jar包内的类结构，能看到Shade后的Jackson类（包名带shaded标识），进而判断版本。
• IntelliJ操作：在项目的External Libraries中找到parquet-jackson的jar包，展开后查看内部类，通过包名和类的版本信息确定内嵌的Jackson版本。
• 查看POM文件：直接查看parquet-jackson的pom.xml，其中会记录Shade的Jackson版本信息，或者查看项目根pom的dependencyManagement配置。

内容的提问来源于stack exchange，提问作者mjspier