| If the shared library, has a transitive dependency to spring core, it is conflicting with spring jars coming from `jdk-tool` plugin. Example. Imagine a custom jar has a dependency on any of spring core components, ex `spring-context` 'com.company.component:library:1.0' --> `org.springframework:spring-context:4.3.8.RELEASE` And lets Imagine a groovy function inside a shared library. `doSomething.groovy` ``` @Grab('com.company.component:library:1.0') import com.company.component.SomeClass def call() { return SomeClass.doSomething() } ``` When `doSomething()` is being called from `Jenkinsfile`, everything constantly crashes with `java.lang.NoSuchMethodError`. That is because, instead of loading transitive dependencies for spring `4.3.8.RELEASE`, a classloader is loading an old `2.5.6` version of spring classes from `jdk-tool` plugin under `$JENKINS_HOME/war/WEB_INF/lib/spring-*2.5.6.jar` Apparently, at the time of method execution, classloader is confused because `jdk-tool` plugin is loaded by default with old spring version. I do see grape downloading correct version of jars to $JENKINS_HOME/.groovy. However, after some debug prints ( with help of https://support.cloudbees.com/hc/en-us/articles/360004592631-What-Plugin-is-providing-this-class- ), it is visible that the classloader is ignoring the version there, and is loading from jdk-tools plugin's jars. Is there any known workaround, or possible fix to issue? |
