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

Type: Bug
Resolution: Unresolved
Priority: Major
Component/s: jdk-tool-plugin, pipeline
Labels:

Similar Issues:
Powered by SuggestiMate

Show

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?

tigran mnatsakanyan created issue - 2019-09-17 15:58

tigran mnatsakanyan made changes - 2019-09-17 15:58

Component/s

New: pipeline [ 21692 ]

tigran mnatsakanyan made changes - 2019-09-17 16:02

Description

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

New: 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`
{noformat}
com.company.component:library:1.0' --> `org.springframework:spring-context:4.3.8.RELEASE{noformat}

And let's Imagine a groovy function inside a shared library.
{noformat}
doSomething.groovy{noformat}
{code:java}
@Grab('com.company.component:library:1.0')
import com.company.component.SomeClass

def call()
{
return SomeClass.doSomething()
}
{code}

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
{noformat}
$JENKINS_HOME/war/WEB-INF/lib/spring-*2.5.6.jar{noformat}

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 [cloudbees-forum|[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?

tigran mnatsakanyan made changes - 2019-09-17 16:02

Description

Original: 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`
{noformat}
com.company.component:library:1.0' --> `org.springframework:spring-context:4.3.8.RELEASE{noformat}

And let's Imagine a groovy function inside a shared library.
{noformat}
doSomething.groovy{noformat}
{code:java}
@Grab('com.company.component:library:1.0')
import com.company.component.SomeClass

def call()
{
return SomeClass.doSomething()
}
{code}

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
{noformat}
$JENKINS_HOME/war/WEB-INF/lib/spring-*2.5.6.jar{noformat}

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 [cloudbees-forum|[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?

New: 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`
{noformat}
com.company.component:library:1.0' --> `org.springframework:spring-context:4.3.8.RELEASE{noformat}

And let's Imagine a groovy function inside a shared library.
{noformat}
doSomething.groovy{noformat}
{code:java}
@Grab('com.company.component:library:1.0')
import com.company.component.SomeClass

def call()
{
return SomeClass.doSomething()
}
{code}

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
{noformat}
$JENKINS_HOME/war/WEB-INF/lib/spring-*2.5.6.jar{noformat}
[link title|http://example.com]

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 [cloudbees-forum|[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?

tigran mnatsakanyan made changes - 2019-09-17 16:03

Description

Original: 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`
{noformat}
com.company.component:library:1.0' --> `org.springframework:spring-context:4.3.8.RELEASE{noformat}

And let's Imagine a groovy function inside a shared library.
{noformat}
doSomething.groovy{noformat}
{code:java}
@Grab('com.company.component:library:1.0')
import com.company.component.SomeClass

def call()
{
return SomeClass.doSomething()
}
{code}

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
{noformat}
$JENKINS_HOME/war/WEB-INF/lib/spring-*2.5.6.jar{noformat}
[link title|http://example.com]

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 [cloudbees-forum|[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?

New: 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`
{noformat}
com.company.component:library:1.0' --> `org.springframework:spring-context:4.3.8.RELEASE{noformat}

And let's Imagine a groovy function inside a shared library.
{noformat}
doSomething.groovy{noformat}
{code:java}
@Grab('com.company.component:library:1.0')
import com.company.component.SomeClass

def call()
{
return SomeClass.doSomething()
}
{code}

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
{noformat}
$JENKINS_HOME/war/WEB-INF/lib/spring-*2.5.6.jar{noformat}

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 [cloud bees forum|[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?

tigran mnatsakanyan made changes - 2019-09-17 16:05

Description

Original: 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`
{noformat}
com.company.component:library:1.0' --> `org.springframework:spring-context:4.3.8.RELEASE{noformat}

And let's Imagine a groovy function inside a shared library.
{noformat}
doSomething.groovy{noformat}
{code:java}
@Grab('com.company.component:library:1.0')
import com.company.component.SomeClass

def call()
{
return SomeClass.doSomething()
}
{code}

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
{noformat}
$JENKINS_HOME/war/WEB-INF/lib/spring-*2.5.6.jar{noformat}

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 [cloud bees forum|[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?

New: 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`
{noformat}
com.company.component:library:1.0' --> `org.springframework:spring-context:4.3.8.RELEASE{noformat}

And let's Imagine a groovy function inside a shared library.
{code:java}
{code:title=doSomething.groovy|borderStyle=solid}

@Grab('com.company.component:library:1.0')
import com.company.component.SomeClass

def call()
{
return SomeClass.doSomething()
}
{code}

When doSomething() is being called from Jenkinsfile, everything constantly crashes with java.lang.NoSuchMethodError.

[cloud bees forum|[https://support.cloudbees.com/hc/en-us/articles/360004592631-What-Plugin-is-providing-this-class-]]

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
{noformat}
$JENKINS_HOME/war/WEB-INF/lib/spring-*2.5.6.jar{noformat}

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 [cloudbees-forum| [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?

tigran mnatsakanyan made changes - 2019-09-17 16:08

Description

Original: 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`
{noformat}
com.company.component:library:1.0' --> `org.springframework:spring-context:4.3.8.RELEASE{noformat}

And let's Imagine a groovy function inside a shared library.
{code:java}
{code:title=doSomething.groovy|borderStyle=solid}

@Grab('com.company.component:library:1.0')
import com.company.component.SomeClass

def call()
{
return SomeClass.doSomething()
}
{code}

When doSomething() is being called from Jenkinsfile, everything constantly crashes with java.lang.NoSuchMethodError.

[cloud bees forum|[https://support.cloudbees.com/hc/en-us/articles/360004592631-What-Plugin-is-providing-this-class-]]

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
{noformat}
$JENKINS_HOME/war/WEB-INF/lib/spring-*2.5.6.jar{noformat}

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 [cloudbees-forum| [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?

New: 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`
{noformat}
com.company.component:library:1.0' --> `org.springframework:spring-context:4.3.8.RELEASE
{noformat}

And let's Imagine a groovy function inside a shared library.

{code:title=doSomething.groovy|borderStyle=solid}

@Grab('com.company.component:library:1.0')

import com.company.component.SomeClass
def call() {
return SomeClass.doSomething()
}

{code}

When doSomething() is being called from Jenkinsfile, everything constantly crashes with java.lang.NoSuchMethodError.

[cloud bees forum|[https://support.cloudbees.com/hc/en-us/articles/360004592631-What-Plugin-is-providing-this-class-]]

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
{noformat}
$JENKINS_HOME/war/WEB-INF/lib/spring-*2.5.6.jar{noformat}

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 [cloudbees-forum| [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?

tigran mnatsakanyan made changes - 2019-09-17 16:09

Description

Original: 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`
{noformat}
com.company.component:library:1.0' --> `org.springframework:spring-context:4.3.8.RELEASE
{noformat}

And let's Imagine a groovy function inside a shared library.

{code:title=doSomething.groovy|borderStyle=solid}

@Grab('com.company.component:library:1.0')

import com.company.component.SomeClass
def call() {
return SomeClass.doSomething()
}

{code}

When doSomething() is being called from Jenkinsfile, everything constantly crashes with java.lang.NoSuchMethodError.

[cloud bees forum|[https://support.cloudbees.com/hc/en-us/articles/360004592631-What-Plugin-is-providing-this-class-]]

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
{noformat}
$JENKINS_HOME/war/WEB-INF/lib/spring-*2.5.6.jar{noformat}

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 [cloudbees-forum| [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?

New: 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`
{noformat}
com.company.component:library:1.0' --> `org.springframework:spring-context:4.3.8.RELEASE
{noformat}

And let's Imagine a groovy function inside a shared library.

{code:title=doSomething.groovy|borderStyle=solid}

@Grab('com.company.component:library:1.0')

import com.company.component.SomeClass
def call() {
return SomeClass.doSomething()
}

{code}

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
{noformat}
$JENKINS_HOME/war/WEB-INF/lib/spring-*2.5.6.jar{noformat}

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

tigran mnatsakanyan made changes - 2019-09-18 09:54

Summary

Original: any transitive dependency to spring, causing version conflict between shared libraries and jdk-tools plugin

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

Assignee:: Devin Nusbaum

Reporter:: tigran mnatsakanyan

Votes:: 1 Vote for this issue

Watchers:: 2 Start watching this issue

Created:: 2019-09-17 15:58

Updated:: 2019-09-19 09:29

Jenkins

Details

Description

Attachments

Activity

People

Dates