Jenkins启动流水线时加载哪些库？及插件与流水线依赖冲突咨询

1. Jenkins 2.107.1的Jersey版本 #

Jenkins 2.107.1默认搭载的是Jersey 2.25.1版本，这是当时Jenkins核心依赖的标准配置。如果你想自己验证，也可以在流水线脚本里加一段代码打印版本信息：

println org.glassfish.jersey.client.ClientBuilder.class.getPackage().getImplementationVersion()

2. Grape加载库被Jira插件覆盖的冲突问题 #

你遇到的Grape动态加载的Java库被Jira插件依赖覆盖的情况，确实是Jenkins早期版本里很常见的类加载冲突场景。原因很直接：Jenkins的所有插件和流水线脚本都跑在同一个JVM进程里，没有独立的类加载隔离机制，类加载器会遵循父优先的规则加载类——要是某个插件先加载了特定版本的Jar包，后面Grape想加载的同类型不同版本的类就会被直接覆盖掉。

这类冲突的可能性其实在Jenkins社区的已知问题中已有记录，属于早期架构设计带来的典型痛点。

3. 如何应对这种版本不确定的稳定性问题 #

针对这种同JVM下依赖共享导致的不确定性，有几个可行的解决方向：

• 对齐依赖版本：在Grape的声明里明确指定和插件依赖一致的版本，从根源上避免版本差异：

  @Grab('org.glassfish.jersey.core:jersey-client:2.25.1')
  import org.glassfish.jersey.client.ClientBuilder
  

• 利用插件的隔离能力：如果你的Jenkins环境允许升级插件，Pipeline Utility Steps插件提供了@GrabExclude注解，能帮你排除掉插件带来的冲突依赖，实现有限的类加载隔离：

  @Grab('com.example:your-library:1.0.0')
  @GrabExclude('org.glassfish.jersey:*')
  import com.example.YourClass
  

• 升级Jenkins版本：较新的Jenkins版本（比如2.300及以上）对流水线的类加载机制做了优化，提供了更清晰的依赖隔离方案，能大幅降低这类冲突的发生概率，这也是更长远的稳定性保障方案。

最后想说的 #

Jenkins早期版本同JVM无隔离的架构确实会给依赖管理带来不少麻烦，尤其是用Grape这种动态加载工具的时候。核心思路要么是主动对齐版本消除差异，要么是利用现有工具做有限隔离。如果对稳定性要求很高，升级到更完善的Jenkins版本会是更省心的选择。

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