Confluence插件集成Azure Key Vault依赖冲突及运行报错咨询

报错的核心原因是对Atlassian插件的类加载规则理解偏差：

• Atlassian SDK内置的依赖检查规则禁止插件将org.slf4j:slf4j-api打入自身插件包，因为Confluence服务端通过OSGi容器已经全局导出了slf4j相关接口，所有插件必须复用容器提供的slf4j实现，避免类版本冲突。你之前直接在Azure依赖中排除了slf4j-api，但没有声明对容器提供的slf4j的依赖，导致插件OSGi清单没有写入slf4j包的导入规则，运行时Azure SDK加载类时找不到org.slf4j.Logger，就会抛出NoClassDefFoundError。
• 你最初遇到的banned dependency报错，本质是Azure SDK传递引入的1.7.25版本slf4j被判定为重复打包，不是slf4j本身不允许使用。

• 保留原有Azure两个依赖中对slf4j-api的排除配置，避免slf4j包被打入插件私有目录触发构建校验失败。
• 在pom.xml中添加slf4j-api的依赖，作用域设为provided，该配置会告诉编译插件和OSGi打包工具：slf4j由运行环境提供，不需要打包进插件，同时会自动在插件清单中生成slf4j包的导入声明：

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>1.7.36</version>
    <scope>provided</scope>
</dependency>

版本选择注意：所有1.7.x系列的slf4j-api都向下兼容，如果后续运行时提示slf4j版本不匹配，直接去Confluence服务端lib目录下查看自带slf4j-api的版本号，把上述配置的版本改成和容器内版本完全一致即可，不要使用2.x系列slf4j，绝大多数Confluence Server版本自带的slf4j都是1.7.x分支。

• 如果你之前自定义过maven-bundle-plugin的Import-Package配置，检查是否存在对org.slf4j*包的排除规则，如果有就删掉，没有自定义配置的话跳过这步即可，Atlassian SDK会自动生成正确的导入规则。
• 如果后续遇到其他传递依赖触发banned dependency报错，先确认报错的依赖包是否是Confluence全局提供的公共包：如果是，就参照slf4j的处理方式，先从第三方依赖中排除该包，再添加对应provided范围的依赖即可，不要直接排除到运行时类缺失。

1. 执行atlas-mvn clean package，确认构建阶段不再出现banned dependency报错。
2. 执行atlas-run启动本地Confluence测试环境，进入插件管理页确认插件状态为已启用，触发调用Azure Key Vault的逻辑，确认不再抛出slf4j相关的类找不到错误。

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