-
Bug
-
Resolution: Unresolved
-
Major
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 let's Imagine a groovy function inside a shared library.
@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 the correct version of jars to $JENKINS_HOME/.groovy. However, after some debug prints ( with help of cloud bees forum ), 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?