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

Gitlab Branch Source Plugin v1.5.1 and upwards unable to checkout code in a multibranch pipeline

    XMLWordPrintable

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • None
    • Jenkins Version: 2.263.4
      Gitlab Branch Source plugin Version: 1.5.1

    Description

      When using the Gitlab Branch source plugin v1.5.1 and upwards in a Multibranch Pipeline, the code checkout is failing with the below error on the Jenkins console:
      Querying the current revision of branch master...[Pipeline] }[Pipeline] // stage[Pipeline] }[Pipeline] // node[Pipeline] End of Pipelinejava.lang.ClassCastException: Cannot cast org.glassfish.jersey.inject.hk2.Hk2InjectionManagerFactory to org.glassfish.jersey.internal.inject.InjectionManagerFactory
      at java.lang.Class.cast(Class.java:3369)
      at org.glassfish.jersey.internal.ServiceFinder$LazyObjectIterator.hasNext(ServiceFinder.java:690)
      at org.glassfish.jersey.internal.inject.Injections.lookupService(Injections.java:88)
      at org.glassfish.jersey.internal.inject.Injections.lookupInjectionManagerFactory(Injections.java:73)
      at org.glassfish.jersey.internal.inject.Injections.createInjectionManager(Injections.java:44)
      at org.glassfish.jersey.client.ClientConfig$State.initRuntime(ClientConfig.java:412)
      at org.glassfish.jersey.internal.util.collection.Values$LazyValueImpl.get(Values.java:317)
      at org.glassfish.jersey.client.ClientConfig.getRuntime(ClientConfig.java:807)
      at org.glassfish.jersey.client.ClientRequest.getClientRuntime(ClientRequest.java:219)
      at org.glassfish.jersey.client.ClientRequest.getInjectionManager(ClientRequest.java:610)
      at org.glassfish.jersey.client.JerseyWebTarget.onBuilder(JerseyWebTarget.java:364)
      at org.glassfish.jersey.client.JerseyWebTarget.request(JerseyWebTarget.java:192)
      at org.glassfish.jersey.client.JerseyWebTarget.request(JerseyWebTarget.java:36)
      at org.gitlab4j.api.GitLabApiClient.invocation(GitLabApiClient.java:783)
      at org.gitlab4j.api.GitLabApiClient.invocation(GitLabApiClient.java:748)
      at org.gitlab4j.api.GitLabApiClient.get(GitLabApiClient.java:399)
      at org.gitlab4j.api.GitLabApiClient.get(GitLabApiClient.java:387)
      at org.gitlab4j.api.AbstractApi.get(AbstractApi.java:213)
      Caused: org.gitlab4j.api.GitLabApiException: Cannot cast org.glassfish.jersey.inject.hk2.Hk2InjectionManagerFactory to org.glassfish.jersey.internal.inject.InjectionManagerFactory
      at org.gitlab4j.api.AbstractApi.handle(AbstractApi.java:655)
      at org.gitlab4j.api.AbstractApi.get(AbstractApi.java:215)
      at org.gitlab4j.api.RepositoryApi.getBranch(RepositoryApi.java:104)
      at io.jenkins.plugins.gitlabbranchsource.GitLabSCMSource.retrieve(GitLabSCMSource.java:257)
      at jenkins.scm.api.SCMSource.fetch(SCMSource.java:582)
      at org.jenkinsci.plugins.workflow.multibranch.SCMVar.getValue(SCMVar.java:101)
      at org.jenkinsci.plugins.workflow.multibranch.SCMVar.getValue(SCMVar.java:58)
      at org.jenkinsci.plugins.workflow.cps.CpsScript.getProperty(CpsScript.java:135)
      at org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:174)
      at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty(ScriptBytecodeAdapter.java:456)
      at org.kohsuke.groovy.sandbox.impl.Checker$7.call(Checker.java:355)
      at org.kohsuke.groovy.sandbox.GroovyInterceptor.onGetProperty(GroovyInterceptor.java:68)
      at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:354)
      at org.kohsuke.groovy.sandbox.impl.Checker$7.call(Checker.java:353)
      at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:357)
      at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:333)
      at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.getProperty(SandboxInvoker.java:29)
      at com.cloudbees.groovy.cps.impl.PropertyAccessBlock.rawGet(PropertyAccessBlock.java:20)
      Caused: java.io.IOException: Failed to retrieve the SCM revision for master
      at io.jenkins.plugins.gitlabbranchsource.GitLabSCMSource.retrieve(GitLabSCMSource.java:297)
      at jenkins.scm.api.SCMSource.fetch(SCMSource.java:582)
      at org.jenkinsci.plugins.workflow.multibranch.SCMVar.getValue(SCMVar.java:101)
      at org.jenkinsci.plugins.workflow.multibranch.SCMVar.getValue(SCMVar.java:58)
      at org.jenkinsci.plugins.workflow.cps.CpsScript.getProperty(CpsScript.java:135)
      at org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:174)
      at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty(ScriptBytecodeAdapter.java:456)
      at org.kohsuke.groovy.sandbox.impl.Checker$7.call(Checker.java:355)
      at org.kohsuke.groovy.sandbox.GroovyInterceptor.onGetProperty(GroovyInterceptor.java:68)
      at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:354)
      at org.kohsuke.groovy.sandbox.impl.Checker$7.call(Checker.java:353)
      at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:357)
      at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:333)
      at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.getProperty(SandboxInvoker.java:29)
      at com.cloudbees.groovy.cps.impl.PropertyAccessBlock.rawGet(PropertyAccessBlock.java:20)
      at WorkflowScript.run(WorkflowScript:8)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.delegateAndExecute(ModelInterpreter.groovy:137)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.executeSingleStage(ModelInterpreter.groovy:661)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.catchRequiredContextForNode(ModelInterpreter.groovy:395)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.catchRequiredContextForNode(ModelInterpreter.groovy:393)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.executeSingleStage(ModelInterpreter.groovy:660)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.evaluateStage(ModelInterpreter.groovy:288)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.toolsBlock(ModelInterpreter.groovy:544)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.toolsBlock(ModelInterpreter.groovy:543)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.evaluateStage(ModelInterpreter.groovy:276)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.withEnvBlock(ModelInterpreter.groovy:443)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.withEnvBlock(ModelInterpreter.groovy:442)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.evaluateStage(ModelInterpreter.groovy:275)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.withCredentialsBlock(ModelInterpreter.groovy:481)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.withCredentialsBlock(ModelInterpreter.groovy:480)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.evaluateStage(ModelInterpreter.groovy:274)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.inDeclarativeAgent(ModelInterpreter.groovy:586)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.inDeclarativeAgent(ModelInterpreter.groovy:585)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.evaluateStage(ModelInterpreter.groovy:272)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.stageInput(ModelInterpreter.groovy:356)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.stageInput(ModelInterpreter.groovy:355)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.evaluateStage(ModelInterpreter.groovy:261)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.inWrappers(ModelInterpreter.groovy:613)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.inWrappers(ModelInterpreter.groovy:612)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.evaluateStage(ModelInterpreter.groovy:259)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.withEnvBlock(ModelInterpreter.groovy:443)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.withEnvBlock(ModelInterpreter.groovy:442)
      at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.evaluateStage(ModelInterpreter.groovy:254)
      at __cps.transform__(Native Method)
      at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.get(PropertyishBlock.java:74)
      at com.cloudbees.groovy.cps.LValueBlock$GetAdapter.receive(LValueBlock.java:30)
      at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.fixName(PropertyishBlock.java:66)
      at sun.reflect.GeneratedMethodAccessor395.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      at java.lang.reflect.Method.invoke(Method.java:498)
      at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
      at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
      at com.cloudbees.groovy.cps.Next.step(Next.java:83)
      at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)
      at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)
      at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:129)
      at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:268)
      at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163)
      at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
      at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:51)
      at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:185)
      at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:400)
      at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$400(CpsThreadGroup.java:96)
      at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:312)
      at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:276)
      at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:67)
      at java.util.concurrent.FutureTask.run(FutureTask.java:266)
      at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:136)
      at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
      at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59)
      at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
      at java.util.concurrent.FutureTask.run(FutureTask.java:266)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
      at java.lang.Thread.run(Thread.java:748)
      Finished: FAILURE
       

      Attachments

        Issue Links

          Activity

            primeos Michael Weiss added a comment -

            Quick information dump (in case it'll help anyone in the future). This seems to be caused by plugin dependency issues/collisions due to incompatible plugin versions. See also https://gitter.im/jenkinsci/gitlab-branch-source-plugin?at=61af31c2abdd6644e3c4b4f6.

             

            I got this error with Jenkins 2.319 LTS when the Jersey 2 API plugin (https://plugins.jenkins.io/jersey2-api/) is installed. A similar error occurs due to the Jira plugin (https://plugins.jenkins.io/jira/, since version 3.7: https://github.com/jenkinsci/jira-plugin/releases/tag/jira-3.7).

             

            The best way to find incompatible plugins is to go inside Jenkins' plugin directory and do something like this:

            root@jenkins plugins # find -type f -name 'jersey*'
            ./jira/WEB-INF/lib/jersey-client-1.19.jar
            ./jira/WEB-INF/lib/jersey-json-1.19.jar
            ./jira/WEB-INF/lib/jersey-core-1.19.jar
            ./gitlab-api/WEB-INF/lib/jersey-apache-connector-2.30.1.jar
            ./gitlab-api/WEB-INF/lib/jersey-client-2.30.1.jar
            ./gitlab-api/WEB-INF/lib/jersey-common-2.30.1.jar
            ./gitlab-api/WEB-INF/lib/jersey-hk2-2.30.1.jar
            ./gitlab-api/WEB-INF/lib/jersey-media-multipart-2.30.1.jar
            ./artifactory/WEB-INF/lib/jersey-apache-connector-2.23.1.jar
            ./artifactory/WEB-INF/lib/jersey-guava-2.23.1.jar
            ./artifactory/WEB-INF/lib/jersey-common-2.23.1.jar
            ./artifactory/WEB-INF/lib/jersey-client-2.23.1.jar

             

            That's from a working setup (without this issue). Before that there were also the following files:
            ./plugins/jersey2-api/WEB-INF/lib/jersey-container-servlet-core-2.35.jar
            ./plugins/jersey2-api/WEB-INF/lib/jersey-media-json-binding-2.35.jar
            ./plugins/jersey2-api/WEB-INF/lib/jersey-common-2.35.jar
            ./plugins/jersey2-api/WEB-INF/lib/jersey-container-servlet-2.35.jar
            ./plugins/jersey2-api/WEB-INF/lib/jersey-apache-connector-2.35.jar
            ./plugins/jersey2-api/WEB-INF/lib/jersey2-api.jar
            ./plugins/jersey2-api/WEB-INF/lib/jersey-client-2.35.jar
            ./plugins/jersey2-api/WEB-INF/lib/jersey-media-jaxb-2.35.jar
            ./plugins/jersey2-api/WEB-INF/lib/jersey-hk2-2.35.jar
            ./plugins/jersey2-api/WEB-INF/lib/jersey-server-2.35.jar
            ./plugins/jersey2-api/WEB-INF/lib/jersey-media-sse-2.35.jar
            ./plugins/jira/WEB-INF/lib/jersey-common-2.35.jar
            ./plugins/jira/WEB-INF/lib/jersey-media-json-jettison-2.35.jar
            ./plugins/jira/WEB-INF/lib/jersey-client-2.35.jar
            ./plugins/jira/WEB-INF/lib/jersey-media-jaxb-2.35.jar
             
            jersey-hk2-2.35.jar caused the issue seen here (Cannot cast org.glassfish.jersey.inject.hk2.Hk2InjectionManagerFactory to org.glassfish.jersey.internal.inject.InjectionManagerFactory) and jersey-media-jaxb-2.35.jar caused this exception:

            {{WARNING i.j.p.g.GitLabSCMSource#retrieve: Exception caught:org.gitlab4j.api.GitLabApiException: class org.glassfish.jersey.jaxb.internal.JaxbAutoDiscoverable cannot be cast to class org.glassfish.jersey.internal.spi.AutoDiscoverable (org.glassfish.jersey.jaxb.internal.JaxbAutoDiscoverable is in unnamed module of loader jenkins.util.AntClassLoader @5dbc55c4; org.glassfish.jersey.internal.spi.AutoDiscoverable is in unnamed module of loader jenkins.util.AntClassLoader @740610ef)
            java.lang.ClassCastException: class org.glassfish.jersey.jaxb.internal.JaxbAutoDiscoverable cannot be cast to class org.glassfish.jersey.internal.spi.AutoDiscoverable (org.glassfish.jersey.jaxb.internal.JaxbAutoDiscoverable is in unnamed module of loader jenkins.util.AntClassLoader @5dbc55c4; org.glassfish.jersey.internal.spi.AutoDiscoverable is in unnamed module of loader jenkins.util.AntClassLoader @740610ef)}}

             

            Hope that helps.

            primeos Michael Weiss added a comment - Quick information dump (in case it'll help anyone in the future). This seems to be caused by plugin dependency issues/collisions due to incompatible plugin versions. See also https://gitter.im/jenkinsci/gitlab-branch-source-plugin?at=61af31c2abdd6644e3c4b4f6 .   I got this error with Jenkins 2.319 LTS when the Jersey 2 API plugin ( https://plugins.jenkins.io/jersey2-api/ ) is installed. A similar error occurs due to the Jira plugin ( https://plugins.jenkins.io/jira/,  since version 3.7: https://github.com/jenkinsci/jira-plugin/releases/tag/jira-3.7 ).   The best way to find incompatible plugins is to go inside Jenkins' plugin directory and do something like this: root@jenkins plugins # find -type f -name 'jersey*' ./jira/WEB-INF/lib/jersey-client-1.19.jar ./jira/WEB-INF/lib/jersey-json-1.19.jar ./jira/WEB-INF/lib/jersey-core-1.19.jar ./gitlab-api/WEB-INF/lib/jersey-apache-connector-2.30.1.jar ./gitlab-api/WEB-INF/lib/jersey-client-2.30.1.jar ./gitlab-api/WEB-INF/lib/jersey-common-2.30.1.jar ./gitlab-api/WEB-INF/lib/jersey-hk2-2.30.1.jar ./gitlab-api/WEB-INF/lib/jersey-media-multipart-2.30.1.jar ./artifactory/WEB-INF/lib/jersey-apache-connector-2.23.1.jar ./artifactory/WEB-INF/lib/jersey-guava-2.23.1.jar ./artifactory/WEB-INF/lib/jersey-common-2.23.1.jar ./artifactory/WEB-INF/lib/jersey-client-2.23.1.jar   That's from a working setup (without this issue). Before that there were also the following files: ./plugins/jersey2-api/WEB-INF/lib/jersey-container-servlet-core-2.35.jar ./plugins/jersey2-api/WEB-INF/lib/jersey-media-json-binding-2.35.jar ./plugins/jersey2-api/WEB-INF/lib/jersey-common-2.35.jar ./plugins/jersey2-api/WEB-INF/lib/jersey-container-servlet-2.35.jar ./plugins/jersey2-api/WEB-INF/lib/jersey-apache-connector-2.35.jar ./plugins/jersey2-api/WEB-INF/lib/jersey2-api.jar ./plugins/jersey2-api/WEB-INF/lib/jersey-client-2.35.jar ./plugins/jersey2-api/WEB-INF/lib/jersey-media-jaxb-2.35.jar ./plugins/jersey2-api/WEB-INF/lib/jersey-hk2-2.35.jar ./plugins/jersey2-api/WEB-INF/lib/jersey-server-2.35.jar ./plugins/jersey2-api/WEB-INF/lib/jersey-media-sse-2.35.jar ./plugins/jira/WEB-INF/lib/jersey-common-2.35.jar ./plugins/jira/WEB-INF/lib/jersey-media-json-jettison-2.35.jar ./plugins/jira/WEB-INF/lib/jersey-client-2.35.jar ./plugins/jira/WEB-INF/lib/jersey-media-jaxb-2.35.jar   jersey-hk2-2.35.jar caused the issue seen here (Cannot cast org.glassfish.jersey.inject.hk2.Hk2InjectionManagerFactory to org.glassfish.jersey.internal.inject.InjectionManagerFactory) and jersey-media-jaxb-2.35.jar caused this exception: {{WARNING i.j.p.g.GitLabSCMSource#retrieve: Exception caught:org.gitlab4j.api.GitLabApiException: class org.glassfish.jersey.jaxb.internal.JaxbAutoDiscoverable cannot be cast to class org.glassfish.jersey.internal.spi.AutoDiscoverable (org.glassfish.jersey.jaxb.internal.JaxbAutoDiscoverable is in unnamed module of loader jenkins.util.AntClassLoader @5dbc55c4; org.glassfish.jersey.internal.spi.AutoDiscoverable is in unnamed module of loader jenkins.util.AntClassLoader @740610ef) java.lang.ClassCastException: class org.glassfish.jersey.jaxb.internal.JaxbAutoDiscoverable cannot be cast to class org.glassfish.jersey.internal.spi.AutoDiscoverable (org.glassfish.jersey.jaxb.internal.JaxbAutoDiscoverable is in unnamed module of loader jenkins.util.AntClassLoader @5dbc55c4; org.glassfish.jersey.internal.spi.AutoDiscoverable is in unnamed module of loader jenkins.util.AntClassLoader @740610ef)}}   Hope that helps.

            So your fix was to remove the jersey2-api plug-in (and its dependants)?

            gordin Christoph Vogtländer added a comment - So your fix was to remove the jersey2-api plug-in (and its dependants)?
            primeos Michael Weiss added a comment - - edited

            Yes. It's of course just a temporary workaround/hack and not a real fix (and only helps if jersey2-api isn't a required dependency yet). I didn't spend more time on it since I expect this to be resolved again with the next LTS version of Jenkins (because I can then update to the newest version of the gitlab-api plugin and that supports the newer Jersey library versions - I didn't bother to check but it lists jersey2-api as a required dependency so the two plugins have to work together). If that wouldn't be the case one needs to update the older/problematic plugins to be compatible with newer Jersey API versions (working together with upstream).

             

            IMO the main issue here is that Jenkins plugins don't always support the latest LTS version of Jenkins and that plugins don't just depend on the functionality of other plugins (e.g., through an API). As we can see here, this quickly creates issues and I assume with enough plugins this quickly results in a plugin dependency hell (https://en.wikipedia.org/wiki/Dependency_hell). Anyway, I doubt these problematic design decisions are easy to resolve now (at this point it might be almost impossible - apart from supporting the latest LTS version).

            (Edit: No offense intended btw. Jenkins is already 10+ years old now and I'm not even sure if most modern plugin systems can avoid such issues as this isn't an uncommon problem in general)

            primeos Michael Weiss added a comment - - edited Yes. It's of course just a temporary workaround/hack and not a real fix (and only helps if jersey2-api isn't a required dependency yet). I didn't spend more time on it since I expect this to be resolved again with the next LTS version of Jenkins (because I can then update to the newest version of the gitlab-api plugin and that supports the newer Jersey library versions - I didn't bother to check but it lists jersey2-api as a required dependency so the two plugins have to work together). If that wouldn't be the case one needs to update the older/problematic plugins to be compatible with newer Jersey API versions (working together with upstream).   IMO the main issue here is that Jenkins plugins don't always support the latest LTS version of Jenkins and that plugins don't just depend on the functionality of other plugins (e.g., through an API). As we can see here, this quickly creates issues and I assume with enough plugins this quickly results in a plugin dependency hell ( https://en.wikipedia.org/wiki/Dependency_hell ). Anyway, I doubt these problematic design decisions are easy to resolve now (at this point it might be almost impossible - apart from supporting the latest LTS version). (Edit: No offense intended btw. Jenkins is already 10+ years old now and I'm not even sure if most modern plugin systems can avoid such issues as this isn't an uncommon problem in general)

            Even after removing the jersey2-api plug-in, gitlab branch source still sometimes fails to notify GitLab with

             

            class org.glassfish.jersey.jaxb.internal.JaxbAutoDiscoverable cannot be cast to class org.glassfish.jersey.internal.spi.AutoDiscoverable
            

             

            My installation regarding jersey* looks like this:

             

            ./gitlab-api/WEB-INF/lib/jersey-media-multipart-2.30.1.jar
            ./gitlab-api/WEB-INF/lib/jersey-hk2-2.30.1.jar
            ./gitlab-api/WEB-INF/lib/jersey-client-2.30.1.jar
            ./gitlab-api/WEB-INF/lib/jersey-common-2.30.1.jar
            ./gitlab-api/WEB-INF/lib/jersey-apache-connector-2.30.1.jar
            ./jira/WEB-INF/lib/jersey-media-json-jettison-2.35.jar
            ./jira/WEB-INF/lib/jersey-common-2.35.jar
            ./jira/WEB-INF/lib/jersey-media-jaxb-2.35.jar
            ./jira/WEB-INF/lib/jersey-client-2.35.jar
            

            I assume that should be OK? So maybe there is another problem with my Jenkins instance?

            primeos can you confirm that in your case gitlab-api and jira work together?

            Or is "jaxb" my problem, now?

            ./gitlab-plugin/WEB-INF/lib/jboss-jaxrs-api_2.1_spec-2.0.1.Final.jar
            ./gitlab-plugin/WEB-INF/lib/resteasy-jaxrs-3.15.3.Final.jar
            ./gitlab-plugin/WEB-INF/lib/jboss-jaxb-api_2.3_spec-2.0.1.Final.jar
            ./discard-old-build/WEB-INF/lib/jaxen-1.1-beta-8.jar
            ./discard-old-build/WEB-INF/lib/jaxme-api-0.3.jar
            ./jackson2-api/WEB-INF/lib/jackson-module-jaxb-annotations-2.13.1.jar
            ./jackson2-api/WEB-INF/lib/jackson-jaxrs-json-provider-2.13.1.jar
            ./jackson2-api/WEB-INF/lib/jackson-jaxrs-base-2.13.1.jar
            ./gitlab-api/WEB-INF/lib/jackson-jaxrs-json-provider-2.10.3.jar
            ./gitlab-api/WEB-INF/lib/jackson-jaxrs-base-2.10.3.jar
            ./gitlab-api/WEB-INF/lib/jackson-module-jaxb-annotations-2.10.3.jar
            ./jira/WEB-INF/lib/jersey-media-jaxb-2.35.jar
            ./jaxb.jpi
            ./jaxb/WEB-INF/lib/jaxb-api-2.3.0.jar
            ./jaxb/WEB-INF/lib/jaxb-core-2.3.0.jar
            ./jaxb/WEB-INF/lib/jaxb-impl-2.3.0.jar
            ./jaxb/WEB-INF/lib/jaxb.jar
            

            Unfortunately, I would not be able to remove jaxb plug-in because cppcheck and xUnit depend on that. 

             

            gordin Christoph Vogtländer added a comment - Even after removing the jersey2-api plug-in, gitlab branch source still sometimes fails to notify GitLab with   class org.glassfish.jersey.jaxb.internal.JaxbAutoDiscoverable cannot be cast to class org.glassfish.jersey.internal.spi.AutoDiscoverable   My installation regarding jersey* looks like this:   ./gitlab-api/WEB-INF/lib/jersey-media-multipart-2.30.1.jar ./gitlab-api/WEB-INF/lib/jersey-hk2-2.30.1.jar ./gitlab-api/WEB-INF/lib/jersey-client-2.30.1.jar ./gitlab-api/WEB-INF/lib/jersey-common-2.30.1.jar ./gitlab-api/WEB-INF/lib/jersey-apache-connector-2.30.1.jar ./jira/WEB-INF/lib/jersey-media-json-jettison-2.35.jar ./jira/WEB-INF/lib/jersey-common-2.35.jar ./jira/WEB-INF/lib/jersey-media-jaxb-2.35.jar ./jira/WEB-INF/lib/jersey-client-2.35.jar I assume that should be OK? So maybe there is another problem with my Jenkins instance? primeos  can you confirm that in your case gitlab-api and jira work together? Or is "jaxb" my problem, now? ./gitlab-plugin/WEB-INF/lib/jboss-jaxrs-api_2.1_spec-2.0.1.Final.jar ./gitlab-plugin/WEB-INF/lib/resteasy-jaxrs-3.15.3.Final.jar ./gitlab-plugin/WEB-INF/lib/jboss-jaxb-api_2.3_spec-2.0.1.Final.jar ./discard-old-build/WEB-INF/lib/jaxen-1.1-beta-8.jar ./discard-old-build/WEB-INF/lib/jaxme-api-0.3.jar ./jackson2-api/WEB-INF/lib/jackson-module-jaxb-annotations-2.13.1.jar ./jackson2-api/WEB-INF/lib/jackson-jaxrs-json-provider-2.13.1.jar ./jackson2-api/WEB-INF/lib/jackson-jaxrs-base-2.13.1.jar ./gitlab-api/WEB-INF/lib/jackson-jaxrs-json-provider-2.10.3.jar ./gitlab-api/WEB-INF/lib/jackson-jaxrs-base-2.10.3.jar ./gitlab-api/WEB-INF/lib/jackson-module-jaxb-annotations-2.10.3.jar ./jira/WEB-INF/lib/jersey-media-jaxb-2.35.jar ./jaxb.jpi ./jaxb/WEB-INF/lib/jaxb-api-2.3.0.jar ./jaxb/WEB-INF/lib/jaxb-core-2.3.0.jar ./jaxb/WEB-INF/lib/jaxb-impl-2.3.0.jar ./jaxb/WEB-INF/lib/jaxb.jar Unfortunately, I would not be able to remove jaxb plug-in because cppcheck and xUnit depend on that.   

            primeos Or maybe I misread your comment. You also downgraded jira? Which version are you using now?

            gordin Christoph Vogtländer added a comment - primeos Or maybe I misread your comment. You also downgraded jira? Which version are you using now?
            primeos Michael Weiss added a comment -

            Yes, I also had to downgrade Jira. ./plugins/jira/WEB-INF/lib/jersey-media-jaxb-2.35.jar is from the problematic setup that caused the same exception on my setup (s. last output in my comment). I downgraded the Jira plugin to version 3.6 (IIRC). Anyway, I've updated all plugins since I've switched to the new LTS version and face different issues now (there's currently a draft PR to make the gitlab-api plugin compatible with the jersey2-api plugin: https://github.com/jenkinsci/gitlab-api-plugin/pull/7).

            But as I noted above the whole plugin ecosystem seems unfortunately bound to such issues as there isn't a proper isolation of dependencies.

            primeos Michael Weiss added a comment - Yes, I also had to downgrade Jira.  ./plugins/jira/WEB-INF/lib/jersey-media-jaxb-2.35.jar is from the problematic setup that caused the same exception on my setup (s. last output in my comment). I downgraded the Jira plugin to version 3.6 (IIRC). Anyway, I've updated all plugins since I've switched to the new LTS version and face different issues now (there's currently a draft PR to make the gitlab-api plugin compatible with the jersey2-api plugin: https://github.com/jenkinsci/gitlab-api-plugin/pull/7 ). But as I noted above the whole plugin ecosystem seems unfortunately bound to such issues as there isn't a proper isolation of dependencies.
            vmspot Vinicius Monteiro added a comment - - edited

            After I upgrade all plugins in my  jenkins ( v.2.332.2)   Gitlab Branch Source Plugin stoped work properly (jenkins job do not checkout git project anymore).

            I did some tests and find out that Jira Plugin  when updated interfer on Gitlab Branch Source. 

            Currently  Jira Plugin is 3.6, with this versions  Gitlab Branch Source Plugin (v. 625.v85cf3a_400cfe) works fine. But when I upgrade  Jira plugin  to v. 3.7.1 Gitlab Branch Source Plugin stops to work.

             

            vmspot Vinicius Monteiro added a comment - - edited After I upgrade all plugins in my  jenkins ( v.2.332.2)   Gitlab Branch Source Plugin stoped work properly (jenkins job do not checkout git project anymore). I did some tests and find out that Jira Plugin  when updated interfer on Gitlab Branch Source.  Currently  Jira Plugin is 3.6, with this versions  Gitlab Branch Source Plugin (v. 625.v85cf3a_400cfe) works fine. But when I upgrade  Jira plugin  to v. 3.7.1 Gitlab Branch Source Plugin stops to work.  
            primeos Michael Weiss added a comment -

            This issue can probably be closed now (or soon): https://github.com/jenkinsci/gitlab-branch-source-plugin/issues/169#issuecomment-1101260680

             

            I didn't test it yet but there have been a lot of awesome improvements to the Jersey dependency mess: https://github.com/jenkinsci/gitlab-api-plugin/pull/7

            primeos Michael Weiss added a comment - This issue can probably be closed now (or soon): https://github.com/jenkinsci/gitlab-branch-source-plugin/issues/169#issuecomment-1101260680   I didn't test it yet but there have been a lot of awesome improvements to the Jersey dependency mess: https://github.com/jenkinsci/gitlab-api-plugin/pull/7

            People

              vmspot Vinicius Monteiro
              santoshdj Santosh
              Votes:
              4 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated: