Jenkins doesn’t automatically load JARs from arbitrary directories (like /lun/data1/jenkins/.jenkins/lib/) into the Groovy sandbox or the pipeline shared library classpath.
Things like -cp or setting CLASSPATH in JAVA_OPTS only affect the initial JVM classpath when Jenkins starts. They don’t influence what’s visible to pipeline or shared library code later on.
A few reasons why this happens:
Pipeline and shared library code runs inside a restricted Groovy sandbox, which is intentionally isolated from the main Jenkins JVM classpath for security.
The pipeline shared library mechanism doesn’t inherit the JVM classpath or pick up JARs from custom paths.
By default, only Jenkins core and installed plugin classes are available.
If you want to use external JARs in a pipeline, here are the supported options:
Grape / @Grab annotations in Groovy — though this can be slow and often requires sandbox approvals.
Pipeline: Classpath Step — exists but is deprecated and not recommended anymore.
Build a Jenkins plugin that bundles your JARs and install it.
Global shared libraries — but note they only load Groovy/Java code from src/ and vars/, not standalone JARs.
Call your Java code externally from the pipeline using sh or bat steps, and provide the JARs there.
So, in short: Jenkins won’t pick up JARs you drop into /lun/data1/jenkins/.jenkins/lib/ for pipeline libraries. To make them available, you’ll need to use one of the supported mechanisms like a plugin, Grape, or an external process.