Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-59410

any dependency to spring is causing version conflict between shared libraries and jdk-tools plugin spring 2.5X

    Details

    • Similar Issues:

      Description

      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.

       

      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 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? 

       

       

        Attachments

          Activity

          Hide
          tigran10 tigran mnatsakanyan added a comment -

          I had a chat with Carlos Sanchez in k8s slack, and very good advice was to go ahead and shade conflicting dependencies with https://maven.apache.org/plugins/maven-shade-plugin or any other plugin supporting shading. That solution worked.

          I am leaving the issue open to check if there are more fundamental solutions available, which does not require recompiling to renaming conflicting classes for the confused classloader. Because it's not always your own code appears as a dependency to add a build plugin to it but could be someone else's jar file.

          Show
          tigran10 tigran mnatsakanyan added a comment - I had a chat with Carlos Sanchez in k8s slack, and very good advice was to go ahead and shade conflicting dependencies with https://maven.apache.org/plugins/maven-shade-plugin or any other plugin supporting shading. That solution worked. I am leaving the issue open to check if there are more fundamental solutions available, which does not require recompiling to renaming conflicting classes for the confused classloader. Because it's not always your own code appears as a dependency to add a build plugin to it but could be someone else's jar file.

            People

            • Assignee:
              dnusbaum Devin Nusbaum
              Reporter:
              tigran10 tigran mnatsakanyan
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: