Maven provided作用域的版本如何生效？配置时需注意什么？

你提到的示例依赖配置如下：

<dependency>
    <groupId>org.eclipse.persistence</groupId>
    <artifactId>eclipselink</artifactId>
    <version>2.6.4</version>
    <scope>provided</scope>
</dependency>

基础规则前置说明 #

Maven给依赖设置provided作用域时，遵循固定的类路径加载规则：

• 编译阶段、单元测试阶段，该依赖会被完整加入类路径，参与代码编译、测试运行
• 最终打包环节，该依赖不会被复制进产出的应用包（WAR、可执行JAR等），需要由部署应用的运行环境（Web服务器、JVM运行容器、云平台运行时）在启动时提供对应的依赖实现

核心问题逐一解答 #

1. 运行时实际使用的依赖版本是哪一个？ #

正常部署场景下，运行时加载的版本由提供该依赖的运行环境决定，和你在pom中配置的2.6.4版本没有直接关联。
但存在两类会影响运行时版本的特殊场景：

• 类加载顺序差异：比如Tomcat的类加载机制是优先加载应用自身WEB-INF/lib目录下的类，再加载容器自带的类。如果哪怕标记了provided，但因为依赖传递、手动放置包文件等原因，把eclipselink的JAR打进了应用的lib目录，运行时会优先加载你自己打进去的版本，而非容器自带的版本。
• 特殊类加载架构：比如OSGi、自定义类加载器的部署环境，依赖版本的匹配逻辑会按照环境本身的类加载隔离规则运行，不一定完全使用容器全局提供的版本。

2. 既然运行时主要由环境决定，为什么还要在provided依赖里配置版本号？ #

配置版本号的核心价值完全服务于编译、开发阶段的确定性，主要有三个实际作用：

• 给Maven明确的依赖拉取目标：如果不写版本号，Maven在编译阶段根本不知道该从仓库拉取哪个版本的eclipselink包，会直接报依赖无法解析的错误，连基础编译流程都走不下去。
• 保证编译期API调用的正确性：你写业务代码时调用的eclipselink接口方法、配置注解，都需要基于这个指定的版本做语法校验。如果编译时拉取的版本和你写的代码不匹配，IDE和Maven编译阶段就会直接报方法不存在、注解无法识别的错误，不需要等到运行时才排查问题。
• 固定编译期依赖版本，避免随机性：如果依赖是从父POM、依赖传递中隐式拉取的，可能会随机拿到仓库里的最新版本。把这个版本号明确写在provided依赖配置里，能把编译用的版本固定下来，不会因为仓库元数据更新、依赖路径变化导致编译用的版本突然变动。

3. 配置provided依赖的版本时，是否需要兼顾Web服务器自带的对应依赖版本？ #

非常建议对齐配置。
如果你编译时使用的依赖版本，和运行环境自带的版本差异过大，很容易出现“编译通过、运行时报错”的问题——比如你编译时调用了2.6.4版本才新增的方法，但是Web服务器自带的eclipselink是2.5版本，运行时加载到容器提供的老版本类时，就会抛出NoSuchMethodError、ClassNotFoundException这类兼容性异常。
实际操作时，只需要在部署对应版本的Web服务器前，查阅官方文档列出的该服务器内置依赖的版本列表，把provided依赖的版本设置成和内置版本一致，就能最大程度避免这类兼容问题。 #

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