Gradle项目如何引入spring-ldap-core两个不同版本解决MethodNotFound报错

方案1（最优，优先选择）：升级内部自定义LDAP依赖适配spring-ldap-core 2.3.3.RELEASE #

• spring-ldap 1.x到2.x的核心API兼容度较高，仅少量边缘方法、废弃接口发生变更。拿到内部自定义LDAP组件的源码后，将其中调用1.x独有方法的逻辑替换为2.x版本的等效实现，统一全项目使用org.springframework.ldap:spring-ldap-core:2.3.3.RELEASE即可从根源解决冲突，无后续维护负担。
• 若无法拿到源码，可以联系内部组件的维护团队提供适配2.x版本的依赖包，是长期来看成本最低的方案。

方案2（次选，适用于内部组件无法修改的场景）：通过Shadow插件重打包隔离旧版依赖 #

如果内部自定义LDAP组件已经停止维护、无法获取源码进行适配，可以通过重打包方式让两个版本的spring-ldap-core共存，不会发生类冲突：

1. 新建一个独立的Gradle子模块，仅引入公司内部自定义LDAP依赖，同时显式引入org.springframework.ldap:spring-ldap-core:1.3.0.RELEASE，在依赖配置中排除所有其他传递引入的spring-ldap-core版本。
2. 给子模块引入Shadow插件，在shadowJar任务中配置包重定向规则：

shadowJar {
    relocate 'org.springframework.ldap', 'shaded.org.springframework.ldap'
    dependencies {
        include dependency('org.springframework.ldap:spring-ldap-core')
        include dependency('你的公司内部自定义LDAP依赖的groupId:artifactId')
    }
}

3. 主项目只依赖这个子模块打包后的产物即可，内部自定义组件运行时会调用重命名后的shaded.org.springframework.ldap包下的1.3.0.RELEASE版本类，Spring Boot自动配置模块调用原生路径下的2.3.3.RELEASE版本类，互不干扰。

不推荐方案 #

不建议使用OSGi等类加载器隔离方案，配置复杂度高、项目侵入性强，后期维护成本远高于上述两种方案。

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