Maven新版本依赖包名不同导致Azure Spark作业部署报错问题

核心冲突为commons-configuration 1.x和2.x版本包名不兼容，无法通过普通依赖排除解决，以下是可行方案：

方案1：启用Spark用户类路径优先（推荐，改造成本最低） #

Azure Spark（含HDInsight、Synapse Spark）默认支持调整类加载优先级，让用户上传的依赖优先级高于集群预装依赖，无需修改任何代码或打包逻辑：

• 提交Spark作业时添加以下配置参数即可：

  spark.driver.userClassPathFirst true
  spark.executor.userClassPathFirst true
  

• 项目依赖中无需排除commons-configuration 1.10版本，直接随业务Jar打包提交即可，集群会优先加载你携带的1.x版本，和预装的2.x版本因为包名不同完全隔离，不会出现类冲突。
• 优点：无额外打包改造，Jar体积无变化，不会影响原有工作流、sh脚本的Zip打包逻辑。
• 注意：如果开启该参数后遇到其他三方依赖和集群预装包的冲突，仅需在业务项目的pom中对应排除冲突的集群预装依赖即可，不需要全量shade整个项目。

方案2：单独重打包内部依赖A（适用于集群不允许开启类路径优先的场景） #

不需要对整个项目做shade，仅单独处理第三方依赖A：

• 新建一个空的Maven项目，仅引入依赖A，使用maven shade插件的重定位功能，仅把A中调用的org.apache.commons.configuration相关代码重定向到org.apache.commons.configuration2，其余代码保持不变。
• 将重打包后的A包上传到团队内部Maven私服，在你的业务项目中排除原依赖A，改为依赖这个重打包后的版本即可。
• 优点：业务项目打包逻辑完全不变，Jar体积几乎无增长，不会影响原有Zip打包流程。

方案3：外部依赖单独加载（适用于不允许修改业务Jar打包逻辑的场景） #

• 单独下载commons-configuration 1.10版本的Jar包，上传到你Azure Spark作业的工作目录。
• 提交作业时通过--jars commons-configuration-1.10.jar参数指定加载该Jar，同时配合方案1的类路径优先参数即可，无需把该依赖打入业务Jar中。
• 优点：业务Jar完全不用修改，仅调整作业提交参数。

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