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

Bytecode compatibility transformer mistakenly corrupts org.apache.ivy.core.settings.IvySettings.triggers

    Details

    • Similar Issues:

      Description

      On two separate Jenkins servers, I'm unable to start Jenkins with the following error,

      org.jvnet.hudson.reactor.ReactorException: java.lang.VerifyError: (class: org/apache/ivy/core/settings/IvySettings, method: getTriggers signature: ()Ljava/util/List;\) Illegal type in constant pool
      	at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:246)
      	at jenkins.InitReactorRunner.run(InitReactorRunner.java:43)
      	at jenkins.model.Jenkins.executeReactor(Jenkins.java:906)
      	at jenkins.model.Jenkins.<init>(Jenkins.java:806)
      	at hudson.model.Hudson.<init>(Hudson.java:81)
      	at hudson.model.Hudson.<init>(Hudson.java:77)
      	at hudson.WebAppMain$3.run(WebAppMain.java:221)
      Caused by: java.lang.VerifyError: (class: org/apache/ivy/core/settings/IvySettings, method: getTriggers signature: ()Ljava/util/List;\) Illegal type in constant pool
      	at hudson.ivy.IvyBuildTrigger.getIvy(IvyBuildTrigger.java:234)
      	at hudson.ivy.IvyBuildTrigger.recomputeModuleDescriptor(IvyBuildTrigger.java:337)
      	at hudson.ivy.IvyBuildTrigger.getModuleDescriptor(IvyBuildTrigger.java:264)
      	at hudson.ivy.IvyBuildTrigger.buildDependencyGraph(IvyBuildTrigger.java:446)
      	at hudson.util.DescribableList.buildDependencyGraph(DescribableList.java:213)
      	at hudson.model.Project.buildDependencyGraph(Project.java:179)
      	at hudson.model.DependencyGraph.build(DependencyGraph.java:95)
      	at jenkins.model.Jenkins.rebuildDependencyGraph(Jenkins.java:3598)
      	at jenkins.model.Jenkins$20.run(Jenkins.java:2577)
      	at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
      	at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
      	at jenkins.model.Jenkins$7.runTask(Jenkins.java:895)
      	at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
      	at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
      	at java.lang.Thread.run(Unknown Source)
      

      I tried different versions, and I see this error with 1.527, 1.528, and 1.529. I've rolled back to 1.526 which is working.

      Let me know if I can provide any additional information. Thanks!

      Update:
      I should also clarify that I'm using free-style projects with "Trigger the build of other projects based on the Ivy dependency management system" post-build action.

      I installed another Jenkins system to debug this issue. On this fresh system, Jenkins started successfully. However, after each build, the verify error showed up in jenkins.err.log,

      Sep 04, 2013 9:10:47 AM SEVERE hudson.model.Executor run
      Executor threw an exception
      java.lang.VerifyError: (class: org/apache/ivy/core/settings/IvySettings, method: getTriggers signature: ()Ljava/util/List;) Illegal type in constant pool
      	at hudson.ivy.IvyBuildTrigger.getIvy(IvyBuildTrigger.java:234)
      	at hudson.ivy.IvyBuildTrigger.recomputeModuleDescriptor(IvyBuildTrigger.java:337)
      	at hudson.ivy.IvyBuildTrigger.perform(IvyBuildTrigger.java:418)
      	at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:776)
      	at hudson.model.Build$BuildExecution.cleanUp(Build.java:192)
      	at hudson.model.Run.execute(Run.java:1648)
      	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      	at hudson.model.ResourceController.execute(ResourceController.java:88)
      	at hudson.model.Executor.run(Executor.java:247)
      

      I turned on -verbose:class, and it looks like the right jar is being used,

      [Loaded org.apache.ivy.core.sort.SortEngineSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
      [Loaded org.apache.ivy.plugins.parser.ParserSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
      [Loaded org.apache.ivy.core.publish.PublishEngineSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
      [Loaded org.apache.ivy.core.deliver.DeliverEngineSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
      [Loaded org.apache.ivy.core.check.CheckEngineSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
      [Loaded org.apache.ivy.core.install.InstallEngineSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
      [Loaded org.apache.ivy.plugins.resolver.ResolverSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
      [Loaded org.apache.ivy.core.resolve.ResolveEngineSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
      [Loaded org.apache.ivy.core.retrieve.RetrieveEngineSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
      [Loaded org.apache.ivy.core.repository.RepositoryManagementEngineSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
      [Loaded org.apache.ivy.core.settings.IvySettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
      [Loaded org.apache.ivy.core.RelativeUrlResolver from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
      [Loaded org.apache.ivy.core.NormalRelativeUrlResolver from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
      [Loaded org.apache.ivy.core.cache.RepositoryCacheManager from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
      [Loaded org.apache.ivy.plugins.lock.LockStrategy from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
      [Loaded org.apache.ivy.util.filter.Filter from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
      [Loaded org.apache.ivy.plugins.conflict.ConflictManager from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
      [Loaded org.apache.ivy.plugins.latest.LatestStrategy from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
      [Loaded org.apache.ivy.core.cache.ResolutionCacheManager from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
      [Loaded java.lang.VerifyError from C:\Java\jdk1.6.0_30_x64\jre\lib\rt.jar]
      

      Also verified that the ivy-2.3.0.jar matched a freshly downloaded copy from apache.

      Stepped through in a debugger. Sadly, there's not much additional information on a VerifyError. In an expression, I was able to resolve other classes in the ivy jar but not IvySettings.

      Searching around the web, VerifyError can be frustrating to deal with. There is Good tools for debugging VerifyError? on StackOverflow. I tried using ASM as suggested in an answer, and no errors were reported. I haven't tried Krakatau yet.

      I noticed that the fresh install of Jenkins 1.529 came with Java 1.7u25. I tried running with Java 1.6(u30) and ran into the same verify error.

        Attachments

          Issue Links

            Activity

            jvmccarthy John McCarthy created issue -
            jvmccarthy John McCarthy made changes -
            Field Original Value New Value
            Description On two separate Jenkins servers, I'm unable to start Jenkins with the following error,

            org.jvnet.hudson.reactor.ReactorException: java.lang.VerifyError: (class: org/apache/ivy/core/settings/IvySettings, method: getTriggers signature: ()Ljava/util/List;) Illegal type in constant pool
            at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:246)
            at jenkins.InitReactorRunner.run(InitReactorRunner.java:43)
            at jenkins.model.Jenkins.executeReactor(Jenkins.java:906)
            at jenkins.model.Jenkins.<init>(Jenkins.java:806)
            at hudson.model.Hudson.<init>(Hudson.java:81)
            at hudson.model.Hudson.<init>(Hudson.java:77)
            at hudson.WebAppMain$3.run(WebAppMain.java:221)
            Caused by: java.lang.VerifyError: (class: org/apache/ivy/core/settings/IvySettings, method: getTriggers signature: ()Ljava/util/List;) Illegal type in constant pool
            at hudson.ivy.IvyBuildTrigger.getIvy(IvyBuildTrigger.java:234)
            at hudson.ivy.IvyBuildTrigger.recomputeModuleDescriptor(IvyBuildTrigger.java:337)
            at hudson.ivy.IvyBuildTrigger.getModuleDescriptor(IvyBuildTrigger.java:264)
            at hudson.ivy.IvyBuildTrigger.buildDependencyGraph(IvyBuildTrigger.java:446)
            at hudson.util.DescribableList.buildDependencyGraph(DescribableList.java:213)
            at hudson.model.Project.buildDependencyGraph(Project.java:179)
            at hudson.model.DependencyGraph.build(DependencyGraph.java:95)
            at jenkins.model.Jenkins.rebuildDependencyGraph(Jenkins.java:3598)
            at jenkins.model.Jenkins$20.run(Jenkins.java:2577)
            at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
            at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
            at jenkins.model.Jenkins$7.runTask(Jenkins.java:895)
            at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
            at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
            at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
            at java.lang.Thread.run(Unknown Source)

            I tried different versions, and I see this error with 1.527, 1.528, and 1.529. I've rolled back to 1.526 which is working.

            Let me know if I can provide any additional information. Thanks!
            On two separate Jenkins servers, I'm unable to start Jenkins with the following error,

            org.jvnet.hudson.reactor.ReactorException: java.lang.VerifyError: (class: org/apache/ivy/core/settings/IvySettings, method: getTriggers signature: ()Ljava/util/List;\) Illegal type in constant pool
            at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:246)
            at jenkins.InitReactorRunner.run(InitReactorRunner.java:43)
            at jenkins.model.Jenkins.executeReactor(Jenkins.java:906)
            at jenkins.model.Jenkins.<init>(Jenkins.java:806)
            at hudson.model.Hudson.<init>(Hudson.java:81)
            at hudson.model.Hudson.<init>(Hudson.java:77)
            at hudson.WebAppMain$3.run(WebAppMain.java:221)
            Caused by: java.lang.VerifyError: (class: org/apache/ivy/core/settings/IvySettings, method: getTriggers signature: ()Ljava/util/List;\) Illegal type in constant pool
            at hudson.ivy.IvyBuildTrigger.getIvy(IvyBuildTrigger.java:234)
            at hudson.ivy.IvyBuildTrigger.recomputeModuleDescriptor(IvyBuildTrigger.java:337)
            at hudson.ivy.IvyBuildTrigger.getModuleDescriptor(IvyBuildTrigger.java:264)
            at hudson.ivy.IvyBuildTrigger.buildDependencyGraph(IvyBuildTrigger.java:446)
            at hudson.util.DescribableList.buildDependencyGraph(DescribableList.java:213)
            at hudson.model.Project.buildDependencyGraph(Project.java:179)
            at hudson.model.DependencyGraph.build(DependencyGraph.java:95)
            at jenkins.model.Jenkins.rebuildDependencyGraph(Jenkins.java:3598)
            at jenkins.model.Jenkins$20.run(Jenkins.java:2577)
            at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
            at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
            at jenkins.model.Jenkins$7.runTask(Jenkins.java:895)
            at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
            at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
            at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
            at java.lang.Thread.run(Unknown Source)

            I tried different versions, and I see this error with 1.527, 1.528, and 1.529. I've rolled back to 1.526 which is working.

            Let me know if I can provide any additional information. Thanks!
            jvmccarthy John McCarthy made changes -
            Description On two separate Jenkins servers, I'm unable to start Jenkins with the following error,

            org.jvnet.hudson.reactor.ReactorException: java.lang.VerifyError: (class: org/apache/ivy/core/settings/IvySettings, method: getTriggers signature: ()Ljava/util/List;\) Illegal type in constant pool
            at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:246)
            at jenkins.InitReactorRunner.run(InitReactorRunner.java:43)
            at jenkins.model.Jenkins.executeReactor(Jenkins.java:906)
            at jenkins.model.Jenkins.<init>(Jenkins.java:806)
            at hudson.model.Hudson.<init>(Hudson.java:81)
            at hudson.model.Hudson.<init>(Hudson.java:77)
            at hudson.WebAppMain$3.run(WebAppMain.java:221)
            Caused by: java.lang.VerifyError: (class: org/apache/ivy/core/settings/IvySettings, method: getTriggers signature: ()Ljava/util/List;\) Illegal type in constant pool
            at hudson.ivy.IvyBuildTrigger.getIvy(IvyBuildTrigger.java:234)
            at hudson.ivy.IvyBuildTrigger.recomputeModuleDescriptor(IvyBuildTrigger.java:337)
            at hudson.ivy.IvyBuildTrigger.getModuleDescriptor(IvyBuildTrigger.java:264)
            at hudson.ivy.IvyBuildTrigger.buildDependencyGraph(IvyBuildTrigger.java:446)
            at hudson.util.DescribableList.buildDependencyGraph(DescribableList.java:213)
            at hudson.model.Project.buildDependencyGraph(Project.java:179)
            at hudson.model.DependencyGraph.build(DependencyGraph.java:95)
            at jenkins.model.Jenkins.rebuildDependencyGraph(Jenkins.java:3598)
            at jenkins.model.Jenkins$20.run(Jenkins.java:2577)
            at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
            at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
            at jenkins.model.Jenkins$7.runTask(Jenkins.java:895)
            at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
            at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
            at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
            at java.lang.Thread.run(Unknown Source)

            I tried different versions, and I see this error with 1.527, 1.528, and 1.529. I've rolled back to 1.526 which is working.

            Let me know if I can provide any additional information. Thanks!
            On two separate Jenkins servers, I'm unable to start Jenkins with the following error,
            {noformat}
            org.jvnet.hudson.reactor.ReactorException: java.lang.VerifyError: (class: org/apache/ivy/core/settings/IvySettings, method: getTriggers signature: ()Ljava/util/List;\) Illegal type in constant pool
            at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:246)
            at jenkins.InitReactorRunner.run(InitReactorRunner.java:43)
            at jenkins.model.Jenkins.executeReactor(Jenkins.java:906)
            at jenkins.model.Jenkins.<init>(Jenkins.java:806)
            at hudson.model.Hudson.<init>(Hudson.java:81)
            at hudson.model.Hudson.<init>(Hudson.java:77)
            at hudson.WebAppMain$3.run(WebAppMain.java:221)
            Caused by: java.lang.VerifyError: (class: org/apache/ivy/core/settings/IvySettings, method: getTriggers signature: ()Ljava/util/List;\) Illegal type in constant pool
            at hudson.ivy.IvyBuildTrigger.getIvy(IvyBuildTrigger.java:234)
            at hudson.ivy.IvyBuildTrigger.recomputeModuleDescriptor(IvyBuildTrigger.java:337)
            at hudson.ivy.IvyBuildTrigger.getModuleDescriptor(IvyBuildTrigger.java:264)
            at hudson.ivy.IvyBuildTrigger.buildDependencyGraph(IvyBuildTrigger.java:446)
            at hudson.util.DescribableList.buildDependencyGraph(DescribableList.java:213)
            at hudson.model.Project.buildDependencyGraph(Project.java:179)
            at hudson.model.DependencyGraph.build(DependencyGraph.java:95)
            at jenkins.model.Jenkins.rebuildDependencyGraph(Jenkins.java:3598)
            at jenkins.model.Jenkins$20.run(Jenkins.java:2577)
            at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
            at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
            at jenkins.model.Jenkins$7.runTask(Jenkins.java:895)
            at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
            at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
            at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
            at java.lang.Thread.run(Unknown Source)
            {noformat}

            I tried different versions, and I see this error with 1.527, 1.528, and 1.529. I've rolled back to 1.526 which is working.

            Let me know if I can provide any additional information. Thanks!

            *Update:*
            I should also clarify that I'm using free-style projects with "Trigger the build of other projects based on the Ivy dependency management system" post-build action.

            I installed another Jenkins system to debug this issue. On this fresh system, Jenkins started successfully. However, after each build, the verify error showed up in {{jenkins.err.log}},
            {noformat}
            Sep 04, 2013 9:10:47 AM SEVERE hudson.model.Executor run
            Executor threw an exception
            java.lang.VerifyError: (class: org/apache/ivy/core/settings/IvySettings, method: getTriggers signature: ()Ljava/util/List;) Illegal type in constant pool
            at hudson.ivy.IvyBuildTrigger.getIvy(IvyBuildTrigger.java:234)
            at hudson.ivy.IvyBuildTrigger.recomputeModuleDescriptor(IvyBuildTrigger.java:337)
            at hudson.ivy.IvyBuildTrigger.perform(IvyBuildTrigger.java:418)
            at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
            at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804)
            at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:776)
            at hudson.model.Build$BuildExecution.cleanUp(Build.java:192)
            at hudson.model.Run.execute(Run.java:1648)
            at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
            at hudson.model.ResourceController.execute(ResourceController.java:88)
            at hudson.model.Executor.run(Executor.java:247)
            {noformat}

            I turned on {{-verbose:class}}, and it looks like the right jar is being used,
            {noformat}
            [Loaded org.apache.ivy.core.sort.SortEngineSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
            [Loaded org.apache.ivy.plugins.parser.ParserSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
            [Loaded org.apache.ivy.core.publish.PublishEngineSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
            [Loaded org.apache.ivy.core.deliver.DeliverEngineSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
            [Loaded org.apache.ivy.core.check.CheckEngineSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
            [Loaded org.apache.ivy.core.install.InstallEngineSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
            [Loaded org.apache.ivy.plugins.resolver.ResolverSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
            [Loaded org.apache.ivy.core.resolve.ResolveEngineSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
            [Loaded org.apache.ivy.core.retrieve.RetrieveEngineSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
            [Loaded org.apache.ivy.core.repository.RepositoryManagementEngineSettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
            [Loaded org.apache.ivy.core.settings.IvySettings from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
            [Loaded org.apache.ivy.core.RelativeUrlResolver from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
            [Loaded org.apache.ivy.core.NormalRelativeUrlResolver from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
            [Loaded org.apache.ivy.core.cache.RepositoryCacheManager from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
            [Loaded org.apache.ivy.plugins.lock.LockStrategy from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
            [Loaded org.apache.ivy.util.filter.Filter from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
            [Loaded org.apache.ivy.plugins.conflict.ConflictManager from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
            [Loaded org.apache.ivy.plugins.latest.LatestStrategy from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
            [Loaded org.apache.ivy.core.cache.ResolutionCacheManager from file:/C:/Program%20Files%20(x86)/Jenkins/plugins/ivy/WEB-INF/lib/ivy-2.3.0.jar]
            [Loaded java.lang.VerifyError from C:\Java\jdk1.6.0_30_x64\jre\lib\rt.jar]
            {noformat}

            Also verified that the {{ivy-2.3.0.jar}} matched a freshly downloaded copy from apache.

            Stepped through in a debugger. Sadly, there's not much additional information on a {{VerifyError}}. In an expression, I was able to resolve other classes in the ivy jar but not {{IvySettings}}.

            Searching around the web, {{VerifyError}} can be frustrating to deal with. There is [_Good tools for debugging VerifyError?_|http://stackoverflow.com/questions/9972439/good-tools-for-debugging-verifyerror] on StackOverflow. I tried using ASM as suggested in an answer, and no errors were reported. I haven't tried Krakatau yet.

            I noticed that the fresh install of Jenkins 1.529 came with Java 1.7u25. I tried running with Java 1.6(u30) and ran into the same verify error.
            Hide
            jvmccarthy John McCarthy added a comment -

            Continuing to look into this, I'm leery of this change introduced in Jenkins 1.527: "Added bytecode transformation driven compatibility ensurance mechanism". I started seeing this issue in 1.527. Looking at the linked discussion, the author discusses changing AbstractProject.triggers. Perhaps the bytecode transformer accidentally targeted the same method name in the ivy library. I'll start digging in that direction.

            Show
            jvmccarthy John McCarthy added a comment - Continuing to look into this, I'm leery of this change introduced in Jenkins 1.527: "Added bytecode transformation driven compatibility ensurance mechanism". I started seeing this issue in 1.527. Looking at the linked discussion , the author discusses changing AbstractProject.triggers . Perhaps the bytecode transformer accidentally targeted the same method name in the ivy library. I'll start digging in that direction.
            Hide
            jvmccarthy John McCarthy added a comment - - edited

            From playing with a debugger, I have confirmed that IvySettings gets past the initial check of spec.mayNeedTransformation(byte[]) in org.jenkinsci.bytecode.Transformer.transform(String, byte[]). Using the eclipse debugger, I was able to use force return to return from transform without modifying the class. After doing this, I did not get the VerifyError in the error log.

            I believe the ivy plugin is being impacted by the jenkins bytecode-compatibility-transformer.

            I'm in over my head when it comes to bytecode manipulation. Should this defect be reassigned? It no longer seems like an ivy plugin issue.

            I'll look into the Jenkins core source to see how the transformer's AdaptField is used. It seems like it's targeting a method name without a specific class in this instance. Perhaps the fix is to target a specific class as well. I suppose a class exception list could be created as well, but such a list would be difficult to maintain.

            Show
            jvmccarthy John McCarthy added a comment - - edited From playing with a debugger, I have confirmed that IvySettings gets past the initial check of spec.mayNeedTransformation(byte[]) in org.jenkinsci.bytecode.Transformer.transform(String, byte[]) . Using the eclipse debugger, I was able to use force return to return from transform without modifying the class. After doing this, I did not get the VerifyError in the error log. I believe the ivy plugin is being impacted by the jenkins bytecode-compatibility-transformer . I'm in over my head when it comes to bytecode manipulation. Should this defect be reassigned? It no longer seems like an ivy plugin issue. I'll look into the Jenkins core source to see how the transformer's AdaptField is used. It seems like it's targeting a method name without a specific class in this instance. Perhaps the fix is to target a specific class as well. I suppose a class exception list could be created as well, but such a list would be difficult to maintain.
            Hide
            jvmccarthy John McCarthy added a comment -

            More details: the bytecode transform appears to only store field name and type. In this case, @AdaptField is used on AbstractProject.triggers,

                @AdaptField(was=List.class)
                protected volatile DescribableList<Trigger<?>,TriggerDescriptor> triggers = new DescribableList<Trigger<?>,TriggerDescriptor>(this);
            

            IvySettings has a field with the same name and the 'was' type of List,

                private List triggers = new ArrayList(); 
            

            Because the bytecode transformer does not store the target class (in NameAndType), any field called triggers with type List is transformed into a DescribableList. The VerifyError comes because IvySettings.getTriggers() expects the original type, List.

            Show
            jvmccarthy John McCarthy added a comment - More details: the bytecode transform appears to only store field name and type. In this case, @AdaptField is used on AbstractProject.triggers , @AdaptField(was=List.class) protected volatile DescribableList<Trigger<?>,TriggerDescriptor> triggers = new DescribableList<Trigger<?>,TriggerDescriptor>( this ); IvySettings has a field with the same name and the 'was' type of List , private List triggers = new ArrayList(); Because the bytecode transformer does not store the target class (in NameAndType ), any field called triggers with type List is transformed into a DescribableList . The VerifyError comes because IvySettings.getTriggers() expects the original type, List .
            jvmccarthy John McCarthy made changes -
            Labels ivy startup bytecode-compatibility-transformer ivy startup
            Hide
            jvmccarthy John McCarthy added a comment -

            Attempted a fix on github,
            https://github.com/jvmccarthy/bytecode-compatibility-transformer/tree/JENKINS-19383
            Plumbing through class name with field and method. I couldn't get CompatabilityTest to pass with or without these changes, otherwise I would submit a pull request. I ran execution tests on these changes, and the transformer is no longer interfering with IvySettings. However, I wasn't able to verify an instance where AbstractProject was transformed.

            Show
            jvmccarthy John McCarthy added a comment - Attempted a fix on github, https://github.com/jvmccarthy/bytecode-compatibility-transformer/tree/JENKINS-19383 Plumbing through class name with field and method. I couldn't get CompatabilityTest to pass with or without these changes, otherwise I would submit a pull request. I ran execution tests on these changes, and the transformer is no longer interfering with IvySettings . However, I wasn't able to verify an instance where AbstractProject was transformed.
            Hide
            jvmccarthy John McCarthy added a comment -

            Kohsuke,
            Greetings. I hope it's not too presumptuous to assign this issue to you, but I believe you are the right person to work on it. I came across what I thought was an ivy plugin issue, but I now believe the problem is in the bytecode-compatability-transformer. The transformer needs to be updated to reference the class where the AdapterField is used. Otherwise, other classes may accidentally get transformed. I created a rough draft of the changes I think need to be made. Please let me know if I can be of any further assistance. Thank you for all your work on Jenkins and in the Java community.

            Show
            jvmccarthy John McCarthy added a comment - Kohsuke, Greetings. I hope it's not too presumptuous to assign this issue to you, but I believe you are the right person to work on it. I came across what I thought was an ivy plugin issue, but I now believe the problem is in the bytecode-compatability-transformer. The transformer needs to be updated to reference the class where the AdapterField is used. Otherwise, other classes may accidentally get transformed. I created a rough draft of the changes I think need to be made. Please let me know if I can be of any further assistance. Thank you for all your work on Jenkins and in the Java community.
            jvmccarthy John McCarthy made changes -
            Assignee Timothy Bingaman [ tbingaman ] Kohsuke Kawaguchi [ kohsuke ]
            Hide
            jvmccarthy John McCarthy added a comment - - edited

            I took another attempt at getting CompatabilityTest to pass, and subclasses like the one defined in Main.testSubType() will be a problem. I was thinking it would be better to track the classes that need to be transformed. The ConstantPoolScanner will report the class that the loading class is extending, but I can't determine any further ancestors from the ConstantPoolScanner data. That wouldn't be a problem if classes were loaded in such a way that the parent class was transformed before the child class. However, I'm not seeing that.

            For example, in the test source we have Foo$Inner. Define class B extends Foo$Inner and class C extends B. When we we try to load class C, if B hasn't been loaded already, Transformer.transform() is called for class C first and then class B. As a result, I don't think we can reliably track the classes that need to be transformed.

            Again, I admit there's much about bytecode manipulation that I don't understand. Still, the longer I look at what is being accomplished here, the more convinced I am that bytecode manipulation is not a desirable solution for backwards compatibility. Versioning the API or adapting the interface some other way, perhaps with a wrapper method to decorate the triggers list, seems less risky.

            Show
            jvmccarthy John McCarthy added a comment - - edited I took another attempt at getting CompatabilityTest to pass, and subclasses like the one defined in Main.testSubType() will be a problem. I was thinking it would be better to track the classes that need to be transformed. The ConstantPoolScanner will report the class that the loading class is extending, but I can't determine any further ancestors from the ConstantPoolScanner data. That wouldn't be a problem if classes were loaded in such a way that the parent class was transformed before the child class. However, I'm not seeing that. For example, in the test source we have Foo$Inner . Define class B extends Foo$Inner and class C extends B . When we we try to load class C , if B hasn't been loaded already, Transformer.transform() is called for class C first and then class B . As a result, I don't think we can reliably track the classes that need to be transformed. Again, I admit there's much about bytecode manipulation that I don't understand. Still, the longer I look at what is being accomplished here, the more convinced I am that bytecode manipulation is not a desirable solution for backwards compatibility. Versioning the API or adapting the interface some other way, perhaps with a wrapper method to decorate the triggers list, seems less risky.
            Hide
            eguess74 eguess74 added a comment -

            Having the same error with 1.535.

            Show
            eguess74 eguess74 added a comment - Having the same error with 1.535.
            Hide
            eguess74 eguess74 added a comment -

            The same thing affected LTS 509.4

            Show
            eguess74 eguess74 added a comment - The same thing affected LTS 509.4
            Hide
            eguess74 eguess74 added a comment -

            confirming working in 1.526

            Show
            eguess74 eguess74 added a comment - confirming working in 1.526
            Hide
            jglick Jesse Glick added a comment -

            Reproducible in 1.509.4:

            • start a new Jenkins installation
            • install Ivy plugin, agree to restart
            • create freestyle job
            • configure the Ivy post-build action, specify ivy.xml and that is all
            • run build

            and you get:

            … hudson.model.Executor run
            SEVERE: Executor threw an exception
            java.lang.VerifyError: (class: org/apache/ivy/core/settings/IvySettings, method: <init> signature: (Lorg/apache/ivy/core/settings/IvyVariableContainer;)V) Illegal type in constant pool
            	at hudson.ivy.IvyBuildTrigger.getIvy(IvyBuildTrigger.java:234)
            	at hudson.ivy.IvyBuildTrigger.recomputeModuleDescriptor(IvyBuildTrigger.java:337)
            	at hudson.ivy.IvyBuildTrigger.perform(IvyBuildTrigger.java:418)
            	at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
            	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:780)
            	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:752)
            	at hudson.model.Build$BuildExecution.cleanUp(Build.java:192)
            	at hudson.model.Run.execute(Run.java:1637)
            	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
            	at hudson.model.ResourceController.execute(ResourceController.java:88)
            	at hudson.model.Executor.run(Executor.java:237)
            
            Show
            jglick Jesse Glick added a comment - Reproducible in 1.509.4: start a new Jenkins installation install Ivy plugin, agree to restart create freestyle job configure the Ivy post-build action, specify ivy.xml and that is all run build and you get: … hudson.model.Executor run SEVERE: Executor threw an exception java.lang.VerifyError: (class: org/apache/ivy/core/settings/IvySettings, method: <init> signature: (Lorg/apache/ivy/core/settings/IvyVariableContainer;)V) Illegal type in constant pool at hudson.ivy.IvyBuildTrigger.getIvy(IvyBuildTrigger.java:234) at hudson.ivy.IvyBuildTrigger.recomputeModuleDescriptor(IvyBuildTrigger.java:337) at hudson.ivy.IvyBuildTrigger.perform(IvyBuildTrigger.java:418) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:780) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:752) at hudson.model.Build$BuildExecution.cleanUp(Build.java:192) at hudson.model.Run.execute(Run.java:1637) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:237)
            jglick Jesse Glick made changes -
            Labels bytecode-compatibility-transformer ivy startup bytecode-compatibility-transformer regression startup
            Priority Major [ 3 ] Blocker [ 1 ]
            Component/s core [ 15593 ]
            jglick Jesse Glick made changes -
            Link This issue is blocking JENKINS-18677 [ JENKINS-18677 ]
            jglick Jesse Glick made changes -
            Summary Error on startup - java.lang.VerifyError in IvySettings.getTriggers() Bytecode compatibility transformer mistakenly corrupts org.apache.ivy.core.settings.IvySettings.triggers
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            Now that JUC is over, I'm back to this issue...

            Show
            kohsuke Kohsuke Kawaguchi added a comment - Now that JUC is over, I'm back to this issue...
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Kohsuke Kawaguchi
            Path:
            core/src/main/java/hudson/ClassicPluginStrategy.java
            http://jenkins-ci.org/commit/jenkins/f98c4627da3c21e37aff82c75c0ef7240e60b4da
            Log:
            JENKINS-19383

            Escape hatch to disable bytecode transformation in case this causes other unforeseen problems.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: core/src/main/java/hudson/ClassicPluginStrategy.java http://jenkins-ci.org/commit/jenkins/f98c4627da3c21e37aff82c75c0ef7240e60b4da Log: JENKINS-19383 Escape hatch to disable bytecode transformation in case this causes other unforeseen problems.
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            As you have discovered, it is by design that the transformer only looks at the name of the field, and not the owning type, and the test case you refer to covers why this is necessary.

            The idea is that this excessive pointless transformation will be optimized away by HotSpot as it can infer that the "instanceof" check will always evaluate to true or false.

            I'm looking into why the result of the transformation results in VerifyError.

            Show
            kohsuke Kohsuke Kawaguchi added a comment - As you have discovered, it is by design that the transformer only looks at the name of the field, and not the owning type, and the test case you refer to covers why this is necessary. The idea is that this excessive pointless transformation will be optimized away by HotSpot as it can infer that the "instanceof" check will always evaluate to true or false. I'm looking into why the result of the transformation results in VerifyError .
            Hide
            dogfood dogfood added a comment -

            Integrated in jenkins_main_trunk #2979
            JENKINS-19383 (Revision f98c4627da3c21e37aff82c75c0ef7240e60b4da)

            Result = SUCCESS
            kohsuke : f98c4627da3c21e37aff82c75c0ef7240e60b4da
            Files :

            • core/src/main/java/hudson/ClassicPluginStrategy.java
            Show
            dogfood dogfood added a comment - Integrated in jenkins_main_trunk #2979 JENKINS-19383 (Revision f98c4627da3c21e37aff82c75c0ef7240e60b4da) Result = SUCCESS kohsuke : f98c4627da3c21e37aff82c75c0ef7240e60b4da Files : core/src/main/java/hudson/ClassicPluginStrategy.java
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Kohsuke Kawaguchi
            Path:
            pom.xml
            src/test/client/Main.java
            src/test/java/CompatibilityTest.java
            src/test/v1/Foo.java
            src/test/v1/Jenkins19383.java
            src/test/v2/Jenkins19383.java
            http://jenkins-ci.org/commit/bytecode-compatibility-transformer/9deadd5e07a7cc8f7db5aba2eef1ee75b706ccb1
            Log:
            reproduced JENKINS-19383

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: pom.xml src/test/client/Main.java src/test/java/CompatibilityTest.java src/test/v1/Foo.java src/test/v1/Jenkins19383.java src/test/v2/Jenkins19383.java http://jenkins-ci.org/commit/bytecode-compatibility-transformer/9deadd5e07a7cc8f7db5aba2eef1ee75b706ccb1 Log: reproduced JENKINS-19383
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Kohsuke Kawaguchi
            Path:
            pom.xml
            src/main/java/org/jenkinsci/bytecode/Transformer.java
            src/test/java/CompatibilityTest.java
            http://jenkins-ci.org/commit/bytecode-compatibility-transformer/c854abbe8edf510f153a6a021e89a05980742f40
            Log:
            Fixed JENKINS-19383.

            "ldc <class>" is only valid after JavaSE 5, so the class file needs to have that version number

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: pom.xml src/main/java/org/jenkinsci/bytecode/Transformer.java src/test/java/CompatibilityTest.java http://jenkins-ci.org/commit/bytecode-compatibility-transformer/c854abbe8edf510f153a6a021e89a05980742f40 Log: Fixed JENKINS-19383 . "ldc <class>" is only valid after JavaSE 5, so the class file needs to have that version number
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            Problem reproduced and fixed in the bytecode compatibility transformer. Four commits up to and including this.

            This test case revealed another problem in the logic around IllegalAccessError.

            Verifying the fix with the Ivy plugin

            Show
            kohsuke Kohsuke Kawaguchi added a comment - Problem reproduced and fixed in the bytecode compatibility transformer. Four commits up to and including this . This test case revealed another problem in the logic around IllegalAccessError . Verifying the fix with the Ivy plugin
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Kohsuke Kawaguchi
            Path:
            changelog.html
            core/pom.xml
            http://jenkins-ci.org/commit/jenkins/27d1a03866e468d2d9b630f636e53ec7804e4ade
            Log:
            [FIXED JENKINS-19383]

            Fixed a bug in bytecode-compatibility-transformer where class file
            format prior to 1.49 cannot have the ldc instruction pointing to a class
            constant.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html core/pom.xml http://jenkins-ci.org/commit/jenkins/27d1a03866e468d2d9b630f636e53ec7804e4ade Log: [FIXED JENKINS-19383] Fixed a bug in bytecode-compatibility-transformer where class file format prior to 1.49 cannot have the ldc instruction pointing to a class constant.
            scm_issue_link SCM/JIRA link daemon made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            jglick Jesse Glick made changes -
            Labels bytecode-compatibility-transformer regression startup bytecode-compatibility-transformer lts-candidate regression startup
            Hide
            dogfood dogfood added a comment -

            Integrated in jenkins_main_trunk #2980
            [FIXED JENKINS-19383] (Revision 27d1a03866e468d2d9b630f636e53ec7804e4ade)

            Result = SUCCESS
            kohsuke : 27d1a03866e468d2d9b630f636e53ec7804e4ade
            Files :

            • core/pom.xml
            • changelog.html
            Show
            dogfood dogfood added a comment - Integrated in jenkins_main_trunk #2980 [FIXED JENKINS-19383] (Revision 27d1a03866e468d2d9b630f636e53ec7804e4ade) Result = SUCCESS kohsuke : 27d1a03866e468d2d9b630f636e53ec7804e4ade Files : core/pom.xml changelog.html
            Hide
            jvmccarthy John McCarthy added a comment -

            Thanks Kohsuke! I'll verify and close this issue when it's released in Jenkins (looks like 1.538).

            Show
            jvmccarthy John McCarthy added a comment - Thanks Kohsuke! I'll verify and close this issue when it's released in Jenkins (looks like 1.538).
            Hide
            jvmccarthy John McCarthy added a comment -

            Verified as fixed in 1.538. Thanks again!

            Show
            jvmccarthy John McCarthy added a comment - Verified as fixed in 1.538. Thanks again!
            jvmccarthy John McCarthy made changes -
            Status Resolved [ 5 ] Closed [ 6 ]
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Kohsuke Kawaguchi
            Path:
            core/src/main/java/hudson/ClassicPluginStrategy.java
            http://jenkins-ci.org/commit/jenkins/371826ac164cf4640ff20cec242c2efb79f5baaa
            Log:
            JENKINS-19383

            Escape hatch to disable bytecode transformation in case this causes other unforeseen problems.

            (cherry picked from commit f98c4627da3c21e37aff82c75c0ef7240e60b4da)

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: core/src/main/java/hudson/ClassicPluginStrategy.java http://jenkins-ci.org/commit/jenkins/371826ac164cf4640ff20cec242c2efb79f5baaa Log: JENKINS-19383 Escape hatch to disable bytecode transformation in case this causes other unforeseen problems. (cherry picked from commit f98c4627da3c21e37aff82c75c0ef7240e60b4da)
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Kohsuke Kawaguchi
            Path:
            core/pom.xml
            http://jenkins-ci.org/commit/jenkins/ded8e0a61028ad212e930a8fc2032de4b0b29319
            Log:
            [FIXED JENKINS-19383]

            Fixed a bug in bytecode-compatibility-transformer where class file
            format prior to 1.49 cannot have the ldc instruction pointing to a class
            constant.

            (cherry picked from commit 27d1a03866e468d2d9b630f636e53ec7804e4ade)

            Conflicts:
            changelog.html

            Compare: https://github.com/jenkinsci/jenkins/compare/4a6b9a18bcfd...ded8e0a61028

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: core/pom.xml http://jenkins-ci.org/commit/jenkins/ded8e0a61028ad212e930a8fc2032de4b0b29319 Log: [FIXED JENKINS-19383] Fixed a bug in bytecode-compatibility-transformer where class file format prior to 1.49 cannot have the ldc instruction pointing to a class constant. (cherry picked from commit 27d1a03866e468d2d9b630f636e53ec7804e4ade) Conflicts: changelog.html Compare: https://github.com/jenkinsci/jenkins/compare/4a6b9a18bcfd...ded8e0a61028
            olivergondza Oliver Gondža made changes -
            Resolution Fixed [ 1 ]
            Status Closed [ 6 ] Reopened [ 4 ]
            olivergondza Oliver Gondža made changes -
            Labels bytecode-compatibility-transformer lts-candidate regression startup 1.532.1-fixed bytecode-compatibility-transformer regression startup
            olivergondza Oliver Gondža made changes -
            Status Reopened [ 4 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            Hide
            tbingaman Timothy Bingaman added a comment -

            Any chance of this being backported to the LTS stream?

            It's currently broken on 1.509.4.

            Looks like the associated bytecode transformer logic was backported to 1.509.4, but this fix hasn't been backported yet.

            Show
            tbingaman Timothy Bingaman added a comment - Any chance of this being backported to the LTS stream? It's currently broken on 1.509.4. Looks like the associated bytecode transformer logic was backported to 1.509.4, but this fix hasn't been backported yet.
            Hide
            danielbeck Daniel Beck added a comment -

            Timothy: Current LTS development is based on 1.532 and will include this fix.

            Given that it appears to be just a dependency update, you should be able to fork Jenkins, incorporate that change in the stable-1.509 branch and build your own "1.509.5" with minimal effort.

            Show
            danielbeck Daniel Beck added a comment - Timothy: Current LTS development is based on 1.532 and will include this fix. Given that it appears to be just a dependency update, you should be able to fork Jenkins, incorporate that change in the stable-1.509 branch and build your own "1.509.5" with minimal effort.
            Hide
            jglick Jesse Glick added a comment -

            @tbingaman the 1.509.x LTS stream is closed; 1.532.1 LTS, which includes the fix, is in preparation.

            Show
            jglick Jesse Glick added a comment - @tbingaman the 1.509.x LTS stream is closed; 1.532.1 LTS, which includes the fix, is in preparation.
            Hide
            tbingaman Timothy Bingaman added a comment -

            ah ok, sweet, no worries then.

            Using 1.509.3 at the moment without issues.

            Will jump on 1.532.1 when it arrives

            Show
            tbingaman Timothy Bingaman added a comment - ah ok, sweet, no worries then. Using 1.509.3 at the moment without issues. Will jump on 1.532.1 when it arrives
            jglick Jesse Glick made changes -
            Link This issue is related to JENKINS-28781 [ JENKINS-28781 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 150831 ] JNJira + In-Review [ 193693 ]

              People

              • Assignee:
                kohsuke Kohsuke Kawaguchi
                Reporter:
                jvmccarthy John McCarthy
              • Votes:
                5 Vote for this issue
                Watchers:
                11 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: