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

Parsing ivy descriptors step fails on a slave when custom ivy settings file is used

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • ivy-plugin
    • None
    • Linux

      We have a global custom ivy settings file that is used by the Jenkins jobs, that are using Ivy build trigger to run. Due to the StackOverflowError we are trying to find a path to migrate all jobs from being free-style to ivy jobs.
      The ivy settings file includes another file specific to the java version basing on the env variable JAVA_VERSION (named like extended.settings-${ENV.JAVA_VERSION})
      On master node this resolves properly and parsing ivy descriptors step works properly. But the same exact build fails if running on a slave.
      I tried to inject all sorts of variables using envInject plugin but it gives me the error all the time:

      Error while reading the default Ivy2.1 settings: failed to load settings from file "our_global_ivy_settings_file".xml: io problem while parsing config file "extended.settings-${ENV.JAVA_VERSION}.xml"

      Note that the variable in the file name was not expanded properly.

        1. ivy.hpi
          1.50 MB
        2. ivy.hpi
          1.50 MB
        3. ivy.hpi
          1.73 MB
        4. ivy.hpi
          1.73 MB

          [JENKINS-15779] Parsing ivy descriptors step fails on a slave when custom ivy settings file is used

          eguess74 added a comment -

          Hi everyone. I need this bug/feature so much that I'm willing to pay 100.00 bucks for it.
          This offer is registered at FreedomSponsors (http://www.freedomsponsors.org/core/issue/95/parsing-ivy-descriptors-step-fails-on-a-slave-when-custom-ivy-settings-file-is-used).
          Once you solve it (according to the acceptance criteria described there), just create a FreedomSponsors account and mark it as resolved (oh, you'll need a Paypal account too)
          I'll then check it out and will gladly pay up!

          If anyone else would like to throw in a few bucks to elevate the priority on this issue, you should check out FreedomSponsors!

          eguess74 added a comment - Hi everyone. I need this bug/feature so much that I'm willing to pay 100.00 bucks for it. This offer is registered at FreedomSponsors ( http://www.freedomsponsors.org/core/issue/95/parsing-ivy-descriptors-step-fails-on-a-slave-when-custom-ivy-settings-file-is-used ). Once you solve it (according to the acceptance criteria described there), just create a FreedomSponsors account and mark it as resolved (oh, you'll need a Paypal account too) I'll then check it out and will gladly pay up! If anyone else would like to throw in a few bucks to elevate the priority on this issue, you should check out FreedomSponsors!

          eguess74 added a comment -

          The offer was increased to $150.00

          eguess74 added a comment - The offer was increased to $150.00

          Bill Yordle added a comment -

          Have you tried clicking advanced on the Ant Builder section of your Ivy Module Configuration and then adding your variable to Properties Text field using the syntax "ENV.JAVA_VERSION=<your value here>"?

          Bill Yordle added a comment - Have you tried clicking advanced on the Ant Builder section of your Ivy Module Configuration and then adding your variable to Properties Text field using the syntax "ENV.JAVA_VERSION=<your value here>"?

          eguess74 added a comment - - edited

          yes, i did - unfortunately it doesn't work. Plus it wouldn't be a good solution because in our build system the project's build.xml file is responsible for specifying the JAVA_VERSION that should be used (if not specified the system uses default one). So i would like to avoid the necessity of specifying project's JAVA_VERSION in more than one place.

          eguess74 added a comment - - edited yes, i did - unfortunately it doesn't work. Plus it wouldn't be a good solution because in our build system the project's build.xml file is responsible for specifying the JAVA_VERSION that should be used (if not specified the system uses default one). So i would like to avoid the necessity of specifying project's JAVA_VERSION in more than one place.

          Would you be willing to create a small testcase project which demonstrates the bug?

          Johno Crawford added a comment - Would you be willing to create a small testcase project which demonstrates the bug?

          eguess74 added a comment -

          @Johno

          Currently, unfortunately, I have no way to reproduce the bug, as all our stuff is in the closed network. I will try to come up with something, but it is not guaranteed. I.e. the bug is easily reproducible on our setup, but it is not easy to reproduce the set up.

          My wild guess is that the variables initialization or usage is working a bit differently when build executed on slave vs master.

          eguess74 added a comment - @Johno Currently, unfortunately, I have no way to reproduce the bug, as all our stuff is in the closed network. I will try to come up with something, but it is not guaranteed. I.e. the bug is easily reproducible on our setup, but it is not easy to reproduce the set up. My wild guess is that the variables initialization or usage is working a bit differently when build executed on slave vs master.

          eguess74 added a comment -

          May be there is a simple race condition or something like that? The fact is that the ivy settings file is specified in the job configuration. When the build starts on the master the variables contained in build.xml are already read by the time the ivy descriptors parsing step starts. On slave though it is not working that way, so the variables are not yet initialized, so the parsing step fails. Does it make any sense?

          eguess74 added a comment - May be there is a simple race condition or something like that? The fact is that the ivy settings file is specified in the job configuration. When the build starts on the master the variables contained in build.xml are already read by the time the ivy descriptors parsing step starts. On slave though it is not working that way, so the variables are not yet initialized, so the parsing step fails. Does it make any sense?

          eguess74 added a comment -

          the offer was increased to $200

          eguess74 added a comment - the offer was increased to $200

          Johno Crawford added a comment - - edited

          To get a better understanding of what is going on I have created a snapshot with verbose logging enabled ( https://issues.jenkins-ci.org/secure/attachment/23032/ivy.hpi ). Would you please try it out and look for log messages which differ from master and slave? Log messages starting with the following might be interesting..

          Configured Ivy using custom settings
          Configured Ivy using default 2.1 settings
          Error while reading the default Ivy 2.1 settings

          Johno Crawford added a comment - - edited To get a better understanding of what is going on I have created a snapshot with verbose logging enabled ( https://issues.jenkins-ci.org/secure/attachment/23032/ivy.hpi ). Would you please try it out and look for log messages which differ from master and slave? Log messages starting with the following might be interesting.. Configured Ivy using custom settings Configured Ivy using default 2.1 settings Error while reading the default Ivy 2.1 settings

          eguess74 added a comment - - edited

          Johno,

          If you don't mind - could you please put your logging code into a git patch that i would be able to apply to the current master branch and assemble the plugin?

          Thanks!

          BTW currently i can't compile master branch:

          c:\git_repos\ivy-plugin\src\main\java\hudson\ivy\IvyBuild.java:501: inconvertibl
          e types
          found : capture#764 of ?
          required: hudson.ivy.IvyModule
          env.put("IVY_MODULE_NAME", ((IvyModule) build.getParent()).getModule
          Name().name);
          ^
          c:\git_repos\ivy-plugin\src\main\java\hudson\ivy\IvyBuild.java:502: inconvertibl
          e types
          found : capture#895 of ?
          required: hudson.ivy.IvyModule
          env.put("IVY_MODULE_ORGANISATION", ((IvyModule) build.getParent()).g
          etModuleName().organisation);
          ^
          Note: Some input files use unchecked or unsafe operations.
          Note: Recompile with -Xlint:unchecked for details.
          2 errors
          [INFO] ------------------------------------------------------------------------
          [ERROR] BUILD ERROR
          [INFO] ------------------------------------------------------------------------
          [INFO] Fatal error compiling

          Embedded error: APT failed: 1
          [INFO] ------------------------------------------------------------------------
          [INFO] Trace
          org.apache.maven.lifecycle.LifecycleExecutionException: Fatal error compiling
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
          ultLifecycleExecutor.java:719)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
          fecycle(DefaultLifecycleExecutor.java:556)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
          ltLifecycleExecutor.java:535)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
          dleFailures(DefaultLifecycleExecutor.java:387)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
          ts(DefaultLifecycleExecutor.java:348)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
          fecycleExecutor.java:180)
          at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
          at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
          at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
          at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:6
          0)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
          java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
          sorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:597)
          at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
          at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
          at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)

          at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
          Caused by: org.apache.maven.plugin.MojoExecutionException: Fatal error compiling

          at org.jenkinsci.maven.plugins.hpi.AbstractCompilerMojo.execute(Abstract
          CompilerMojo.java:491)
          at org.jenkinsci.maven.plugins.hpi.CompilerMojo.execute(CompilerMojo.jav
          a:111)
          at org.jenkinsci.maven.plugins.hpi.AptMojo.execute(AptMojo.java:24)
          at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
          nManager.java:490)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
          ultLifecycleExecutor.java:694)
          ... 17 more
          Caused by: org.codehaus.plexus.compiler.CompilerException: APT failed: 1
          at org.jenkinsci.maven.plugins.hpi.AptCompiler.compileInProcess(AptCompi
          ler.java:66)
          at org.jenkinsci.maven.plugins.hpi.AptCompiler.compile(AptCompiler.java:
          50)
          at org.jenkinsci.maven.plugins.hpi.AbstractCompilerMojo.execute(Abstract
          CompilerMojo.java:486)
          ... 21 more
          [INFO] ------------------------------------------------------------------------
          [INFO] Total time: 23 seconds
          [INFO] Finished at: Tue Jan 08 17:57:20 EST 2013
          [INFO] Final Memory: 49M/63M
          [INFO] ------------------------------------------------------------------------

          eguess74 added a comment - - edited Johno, If you don't mind - could you please put your logging code into a git patch that i would be able to apply to the current master branch and assemble the plugin? Thanks! BTW currently i can't compile master branch: c:\git_repos\ivy-plugin\src\main\java\hudson\ivy\IvyBuild.java:501: inconvertibl e types found : capture#764 of ? required: hudson.ivy.IvyModule env.put("IVY_MODULE_NAME", ((IvyModule) build.getParent()).getModule Name().name); ^ c:\git_repos\ivy-plugin\src\main\java\hudson\ivy\IvyBuild.java:502: inconvertibl e types found : capture#895 of ? required: hudson.ivy.IvyModule env.put("IVY_MODULE_ORGANISATION", ((IvyModule) build.getParent()).g etModuleName().organisation); ^ Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 2 errors [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Fatal error compiling Embedded error: APT failed: 1 [INFO] ------------------------------------------------------------------------ [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Fatal error compiling at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:719) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:6 0) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Fatal error compiling at org.jenkinsci.maven.plugins.hpi.AbstractCompilerMojo.execute(Abstract CompilerMojo.java:491) at org.jenkinsci.maven.plugins.hpi.CompilerMojo.execute(CompilerMojo.jav a:111) at org.jenkinsci.maven.plugins.hpi.AptMojo.execute(AptMojo.java:24) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:694) ... 17 more Caused by: org.codehaus.plexus.compiler.CompilerException: APT failed: 1 at org.jenkinsci.maven.plugins.hpi.AptCompiler.compileInProcess(AptCompi ler.java:66) at org.jenkinsci.maven.plugins.hpi.AptCompiler.compile(AptCompiler.java: 50) at org.jenkinsci.maven.plugins.hpi.AbstractCompilerMojo.execute(Abstract CompilerMojo.java:486) ... 21 more [INFO] ------------------------------------------------------------------------ [INFO] Total time: 23 seconds [INFO] Finished at: Tue Jan 08 17:57:20 EST 2013 [INFO] Final Memory: 49M/63M [INFO] ------------------------------------------------------------------------

          Johno Crawford added a comment - - edited

          I don't mind at all, here it is https://github.com/johnou/ivy-plugin/commit/16f68088e6c3c0485a3f056c08ece1610e6f3cd3.patch . I am using master too. I assume there must be something wrong with your development environment, you could try moving your local ~/.m2/repository folder and then "mvn compile". I have found that sometimes I run into conflicts because of artifacts which were downloaded from another repo.

          Johno Crawford added a comment - - edited I don't mind at all, here it is https://github.com/johnou/ivy-plugin/commit/16f68088e6c3c0485a3f056c08ece1610e6f3cd3.patch . I am using master too. I assume there must be something wrong with your development environment, you could try moving your local ~/.m2/repository folder and then "mvn compile". I have found that sometimes I run into conflicts because of artifacts which were downloaded from another repo.

          eguess74 added a comment - - edited

          We have resolved compilation problem. I don't know why I'm the only one who got this, but It seems to be a Java bug:
          http://stackoverflow.com/questions/4829576/javac-error-inconvertible-types-with-generics

          So if the IvyBuild.java is changed in this way it compiles OK:

           
          diff --git a/src/main/java/hudson/ivy/IvyBuild.java b/src/main/java/hudson/ivy/IvyBuild.java
          index fbe04d6..d98fb80 100644
          --- a/src/main/java/hudson/ivy/IvyBuild.java
          +++ b/src/main/java/hudson/ivy/IvyBuild.java
          @@ -498,8 +498,13 @@ public class IvyBuild extends AbstractIvyBuild<IvyModule, IvyBuild> {
                   }
          
                   public void buildEnvVars(AbstractBuild<?, ?> build, EnvVars env) {
          -            env.put("IVY_MODULE_NAME", ((IvyModule) build.getParent()).getModuleName().name);
          -            env.put("IVY_MODULE_ORGANISATION", ((IvyModule) build.getParent()).getModuleName().organisation);
          +            //env.put("IVY_MODULE_NAME", ((IvyModule) build.getParent()).getModuleName().name);
          +            //env.put("IVY_MODULE_ORGANISATION", ((IvyModule) build.getParent()).getModuleName().organisation);
          +            Object o = build.getParent();
          +            ModuleName n = ( ( IvyModule ) o ).getModuleName() ;
          +            env.put("IVY_MODULE_NAME", n.name);
          +            env.put("IVY_MODULE_ORGANISATION", n.organisation);
          +
                   }
               }
           }
          

          eguess74 added a comment - - edited We have resolved compilation problem. I don't know why I'm the only one who got this, but It seems to be a Java bug: http://stackoverflow.com/questions/4829576/javac-error-inconvertible-types-with-generics So if the IvyBuild.java is changed in this way it compiles OK: diff --git a/src/main/java/hudson/ivy/IvyBuild.java b/src/main/java/hudson/ivy/IvyBuild.java index fbe04d6..d98fb80 100644 --- a/src/main/java/hudson/ivy/IvyBuild.java +++ b/src/main/java/hudson/ivy/IvyBuild.java @@ -498,8 +498,13 @@ public class IvyBuild extends AbstractIvyBuild<IvyModule, IvyBuild> { } public void buildEnvVars(AbstractBuild<?, ?> build, EnvVars env) { - env.put("IVY_MODULE_NAME", ((IvyModule) build.getParent()).getModuleName().name); - env.put("IVY_MODULE_ORGANISATION", ((IvyModule) build.getParent()).getModuleName().organisation); + //env.put("IVY_MODULE_NAME", ((IvyModule) build.getParent()).getModuleName().name); + //env.put("IVY_MODULE_ORGANISATION", ((IvyModule) build.getParent()).getModuleName().organisation); + Object o = build.getParent(); + ModuleName n = ( ( IvyModule ) o ).getModuleName() ; + env.put("IVY_MODULE_NAME", n.name); + env.put("IVY_MODULE_ORGANISATION", n.organisation); + } } }

          What JDK are you using? Latest 1.6?

          Johno Crawford added a comment - What JDK are you using? Latest 1.6?

          I also committed a change ( https://github.com/jenkinsci/ivy-plugin/commit/708cc3e1c1bb66fe1a7415e305f2f8b7eefa6d06 ) to the IvyBuild file which hopefully fixes the compile bug.

          Johno Crawford added a comment - I also committed a change ( https://github.com/jenkinsci/ivy-plugin/commit/708cc3e1c1bb66fe1a7415e305f2f8b7eefa6d06 ) to the IvyBuild file which hopefully fixes the compile bug.

          eguess74 added a comment -

          Your compilation fix doesn't seem to work:

          c:\git_repos\ivy-plugin\src\main\java\hudson\ivy\IvyBuild.java:503: inconvertible types
          found : hudson.model.AbstractProject<capture#764 of ?,capture#607 of ?>
          required: hudson.ivy.IvyModule
          env.put("IVY_MODULE_NAME", ((IvyModule) buildParent).getModuleName().name);
          ^
          c:\git_repos\ivy-plugin\src\main\java\hudson\ivy\IvyBuild.java:504: inconvertible types
          found : hudson.model.AbstractProject<capture#113 of ?,capture#238 of ?>
          required: hudson.ivy.IvyModule
          env.put("IVY_MODULE_ORGANISATION", ((IvyModule) buildParent).getModuleName().organisation);
          ^
          Note: c:\git_repos\ivy-plugin\src\main\java\hudson\ivy\IvyBuild.java uses unchecked or unsafe operations.
          Note: Recompile with -Xlint:unchecked for details.
          2 errors
          [INFO] ------------------------------------------------------------------------
          [ERROR] BUILD ERROR
          [INFO] ------------------------------------------------------------------------
          [INFO] Fatal error compiling

          my environment:

          $ java -version
          java version "1.6.0_37"
          Java(TM) SE Runtime Environment (build 1.6.0_37-b06)
          Java HotSpot(TM) Client VM (build 20.12-b01, mixed mode, sharing)

          $ mvn -version
          Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
          Java version: 1.6.0_14
          Java home: c:\Program Files\Java\jdk1.6.0_14\jre
          Default locale: en_US, platform encoding: Cp1252
          OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"

          eguess74 added a comment - Your compilation fix doesn't seem to work: c:\git_repos\ivy-plugin\src\main\java\hudson\ivy\IvyBuild.java:503: inconvertible types found : hudson.model.AbstractProject<capture#764 of ?,capture#607 of ?> required: hudson.ivy.IvyModule env.put("IVY_MODULE_NAME", ((IvyModule) buildParent).getModuleName().name); ^ c:\git_repos\ivy-plugin\src\main\java\hudson\ivy\IvyBuild.java:504: inconvertible types found : hudson.model.AbstractProject<capture#113 of ?,capture#238 of ?> required: hudson.ivy.IvyModule env.put("IVY_MODULE_ORGANISATION", ((IvyModule) buildParent).getModuleName().organisation); ^ Note: c:\git_repos\ivy-plugin\src\main\java\hudson\ivy\IvyBuild.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 2 errors [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Fatal error compiling my environment: $ java -version java version "1.6.0_37" Java(TM) SE Runtime Environment (build 1.6.0_37-b06) Java HotSpot(TM) Client VM (build 20.12-b01, mixed mode, sharing) $ mvn -version Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400) Java version: 1.6.0_14 Java home: c:\Program Files\Java\jdk1.6.0_14\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"

          eguess74 added a comment -

          As for the main problem, i "greped" the jenkins log:

          Every job has the an entry in the jenkins log file

          Configured Ivy using custom settings path/to/our_global_ivy_settings_file.xml

          I have found NO entries for the lines:

          Configured Ivy using default 2.1 settings
          Error while reading the default Ivy 2.1 settings

          eguess74 added a comment - As for the main problem, i "greped" the jenkins log: Every job has the an entry in the jenkins log file Configured Ivy using custom settings path/to/our_global_ivy_settings_file.xml I have found NO entries for the lines: Configured Ivy using default 2.1 settings Error while reading the default Ivy 2.1 settings

          Johno Crawford added a comment - - edited

          So you have Java 1.6.0_37 installed but Maven is using Java 1.6.0_14. Is your JAVA_HOME environment variable correct? Regardless I have added the Object workaround.

          Johno Crawford added a comment - - edited So you have Java 1.6.0_37 installed but Maven is using Java 1.6.0_14. Is your JAVA_HOME environment variable correct? Regardless I have added the Object workaround.

          Would you please try the latest snapshot ( https://issues.jenkins-ci.org/secure/attachment/23055/ivy.hpi ). I have added logging to spit out the Java home and changed IvyXmlParser to load EnvVars. Changeset available at https://github.com/jenkinsci/ivy-plugin/commit/cdf08c9adde721f5ad93b9d0e79f4c0c013c4e0d.patch

          Johno Crawford added a comment - Would you please try the latest snapshot ( https://issues.jenkins-ci.org/secure/attachment/23055/ivy.hpi ). I have added logging to spit out the Java home and changed IvyXmlParser to load EnvVars. Changeset available at https://github.com/jenkinsci/ivy-plugin/commit/cdf08c9adde721f5ad93b9d0e79f4c0c013c4e0d.patch

          eguess74 added a comment - - edited

          your compilation workaround works! As for the main issue:

          On the master the build works fine. On the slave it fails with the exception below. Same code, same project, same settings:

           
          ...
          Parsing Ivy Descriptor Files
          ERROR: Failed to parse ivy.xml files
          java.io.IOException  : Remote call on <hostname> failed
              at hudson.remoting.Channel.call(Channel.java:673)
              at hudson.FilePath.act(FilePath.java:939)
              at hudson.ivy.IvyModuleSetBuild$RunnerImpl.parseIvyDescriptorFiles(IvyModuleSetBuild.java:523)      
          at hudson.ivy.IvyModuleSetBuild$RunnerImpl.doRun(IvyModuleSetBuild.java:365)
              at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:589)
              at hudson.model.Run.execute(Run.java:1516) 
              at hudson.model.Run.run(Run.java:1462)  
              at hudson.ivy.IvyModuleSetBuild.run(IvyModuleSetBuild.java:281)  
              at hudson.model.ResourceController.execute(ResourceController.java:88)  
              at hudson.model.Executor.run(Executor.java:236)  
          Caused by:java.lang.ExceptionInInitializerError
           at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.getIvySettingsFile(IvyModuleSetBuild.java:893)
              at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.getIvy(IvyModuleSetBuild.java:829)  
              at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call(IvyModuleSetBuild.java:778) 
              at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call(IvyModuleSetBuild.java:741) 
              at hudson.remoting.UserRequest.perform(UserRequest.java:118)
              at hudson.remoting.UserRequest.perform(UserRequest.java:48)
              at hudson.remoting.Request$2.run(Request.java:326) 
              at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
              at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) 
              at java.util.concurrent.FutureTask.run(FutureTask.java:138) 
              at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) 
              at java.lang.Thread.run(Thread.java:662) 
          Caused by:java.lang.NullPointerException
           at hudson.model.Descriptor.getConfigFile(Descriptor.java:786)
              at hudson.model.Descriptor.load(Descriptor.java:774)
              at hudson.ivy.IvyModuleSet$DescriptorImpl.<init>(IvyModuleSet.java:769)
              at hudson.ivy.IvyModuleSet.<clinit>(IvyModuleSet.java:757) 
              ... 13 more 
          

          eguess74 added a comment - - edited your compilation workaround works! As for the main issue: On the master the build works fine. On the slave it fails with the exception below. Same code, same project, same settings: ... Parsing Ivy Descriptor Files ERROR: Failed to parse ivy.xml files java.io.IOException : Remote call on <hostname> failed at hudson.remoting.Channel.call(Channel.java:673) at hudson.FilePath.act(FilePath.java:939) at hudson.ivy.IvyModuleSetBuild$RunnerImpl.parseIvyDescriptorFiles(IvyModuleSetBuild.java:523) at hudson.ivy.IvyModuleSetBuild$RunnerImpl.doRun(IvyModuleSetBuild.java:365) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:589) at hudson.model.Run.execute(Run.java:1516) at hudson.model.Run.run(Run.java:1462) at hudson.ivy.IvyModuleSetBuild.run(IvyModuleSetBuild.java:281) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by:java.lang.ExceptionInInitializerError at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.getIvySettingsFile(IvyModuleSetBuild.java:893) at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.getIvy(IvyModuleSetBuild.java:829) at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call(IvyModuleSetBuild.java:778) at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call(IvyModuleSetBuild.java:741) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by:java.lang.NullPointerException at hudson.model.Descriptor.getConfigFile(Descriptor.java:786) at hudson.model.Descriptor.load(Descriptor.java:774) at hudson.ivy.IvyModuleSet$DescriptorImpl.<init>(IvyModuleSet.java:769) at hudson.ivy.IvyModuleSet.<clinit>(IvyModuleSet.java:757) ... 13 more

          Code changed in jenkins
          User: johnou
          Path:
          src/main/java/hudson/ivy/IvyModuleSetBuild.java
          http://jenkins-ci.org/commit/ivy-plugin/d7e77eec8959b70afc44e94bb38468ac8aca46d2
          Log:
          JENKINS-15779: Parsing ivy descriptors step fails on a slave when custom ivy settings file is used.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: johnou Path: src/main/java/hudson/ivy/IvyModuleSetBuild.java http://jenkins-ci.org/commit/ivy-plugin/d7e77eec8959b70afc44e94bb38468ac8aca46d2 Log: JENKINS-15779 : Parsing ivy descriptors step fails on a slave when custom ivy settings file is used.

          Johno Crawford added a comment - - edited

          Johno Crawford added a comment - - edited I am feeling good about this snapshot ( https://issues.jenkins-ci.org/secure/attachment/23081/ivy.hpi ).. Patch available at https://github.com/jenkinsci/ivy-plugin/commit/d7e77eec8959b70afc44e94bb38468ac8aca46d2.patch (do not apply the patch from JENKINS-15774 ).

          eguess74 added a comment - - edited

          I applied the patch to the current master and assembled the plugin - it works when running on master and fails on a slave with NPE

          Parsing Ivy Descriptor Files
          Error while reading the default Ivy 2.1 settings: failed to load settings from file:../custom.ivy.settings.xml: io problem while parsing config file: ../custom.ivy.settings-${ENV.JAVA_VERSION}.xml
          [Ljava.lang.StackTraceElement;@10a6bf3
          ERROR: Failed to parse ivy.xml files
          java.io.IOException: Unable to parse ivy descriptors
              at hudson.ivy.IvyModuleSetBuild$RunnerImpl.parseIvyDescriptorFiles(IvyModuleSetBuild.java:530)
              at hudson.ivy.IvyModuleSetBuild$RunnerImpl.doRun(IvyModuleSetBuild.java:366)
              at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:589)
              at hudson.model.Run.execute(Run.java:1516)
              at hudson.model.Run.run(Run.java:1462)
              at hudson.ivy.IvyModuleSetBuild.run(IvyModuleSetBuild.java:282)
              at hudson.model.ResourceController.execute(ResourceController.java:88)
              at hudson.model.Executor.run(Executor.java:236)
          Caused by: java.lang.NullPointerException
              at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call(IvyModuleSetBuild.java:793)
              at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call(IvyModuleSetBuild.java:742)
              at hudson.remoting.UserRequest.perform(UserRequest.java:118)
              at hudson.remoting.UserRequest.perform(UserRequest.java:48)
              at hudson.remoting.Request$2.run(Request.java:326)
              at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
              at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
              at java.util.concurrent.FutureTask.run(FutureTask.java:138)
              at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
              at java.lang.Thread.run(Thread.java:662) 
          

          eguess74 added a comment - - edited I applied the patch to the current master and assembled the plugin - it works when running on master and fails on a slave with NPE Parsing Ivy Descriptor Files Error while reading the default Ivy 2.1 settings: failed to load settings from file:../custom.ivy.settings.xml: io problem while parsing config file: ../custom.ivy.settings-${ENV.JAVA_VERSION}.xml [Ljava.lang.StackTraceElement;@10a6bf3 ERROR: Failed to parse ivy.xml files java.io.IOException: Unable to parse ivy descriptors at hudson.ivy.IvyModuleSetBuild$RunnerImpl.parseIvyDescriptorFiles(IvyModuleSetBuild.java:530) at hudson.ivy.IvyModuleSetBuild$RunnerImpl.doRun(IvyModuleSetBuild.java:366) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:589) at hudson.model.Run.execute(Run.java:1516) at hudson.model.Run.run(Run.java:1462) at hudson.ivy.IvyModuleSetBuild.run(IvyModuleSetBuild.java:282) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: java.lang.NullPointerException at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call(IvyModuleSetBuild.java:793) at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call(IvyModuleSetBuild.java:742) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662)

          Where is custom.ivy.settings-${ENV.JAVA_VERSION}.xml defined? Have you set it in "Ivy settings property files"?

          Johno Crawford added a comment - Where is custom.ivy.settings-${ENV.JAVA_VERSION}.xml defined? Have you set it in "Ivy settings property files"?

          eguess74 added a comment -

          it seems we got to the root of the problem:

          Before the actual build starts Jenkins attempts to parse the ivy descriptors in order to determine which ivy modules are supposed to be built. This step doesn't exist when ivy build trigger is used, only when the ivy type job is used. This step is failing to parse ivy descriptors when running on slave as the environment variables are not passed to the slave from master. More than that - this step is not needed unless the build is specified to be incremental or the build is having modules as separate jobs.
          It works on master because we are specifying a default value for the JAVA_VERSION property in jenkins startup script. Interestingly enough injecting this variable into the build or slave configuration (Node proeprties) doesn't help, so it keeps failing on the slave.

          Therefore the issue is now broken to two parts:
          1. The parsing descriptors step should not be executed if the build doesn't require it (that should solve our problem as we are not using neither incremental or separate module-job kind of builds) For that latest changes are provided here:

          https://github.com/jenkinsci/ivy-plugin/tree/ivy-descriptors

          2. It still open question how to make this parsing step to work on a slave with this kind of variables in case of incremental build or separate module-jobs

          eguess74 added a comment - it seems we got to the root of the problem: Before the actual build starts Jenkins attempts to parse the ivy descriptors in order to determine which ivy modules are supposed to be built. This step doesn't exist when ivy build trigger is used, only when the ivy type job is used. This step is failing to parse ivy descriptors when running on slave as the environment variables are not passed to the slave from master. More than that - this step is not needed unless the build is specified to be incremental or the build is having modules as separate jobs. It works on master because we are specifying a default value for the JAVA_VERSION property in jenkins startup script. Interestingly enough injecting this variable into the build or slave configuration (Node proeprties) doesn't help, so it keeps failing on the slave. Therefore the issue is now broken to two parts: 1. The parsing descriptors step should not be executed if the build doesn't require it (that should solve our problem as we are not using neither incremental or separate module-job kind of builds) For that latest changes are provided here: https://github.com/jenkinsci/ivy-plugin/tree/ivy-descriptors 2. It still open question how to make this parsing step to work on a slave with this kind of variables in case of incremental build or separate module-jobs

          eguess74 added a comment -

          I can now confirm that the build is not failing anymore on the slave as the parsing step was removed for builds not using the modules. The build still fails with the same exception if "build modules as separate jobs" or "incremental build" is selected.

          eguess74 added a comment - I can now confirm that the build is not failing anymore on the slave as the parsing step was removed for builds not using the modules. The build still fails with the same exception if "build modules as separate jobs" or "incremental build" is selected.

          Jesse Glick added a comment -

          Jesse Glick added a comment - https://github.com/jenkinsci/ivy-plugin/compare/ivy-descriptors is the more useful link by the way.

          Dmitry Danilson added a comment - - edited

          Note that the variable in the file name was not expanded properly.

          Looks like it is the root of the issue: environment variables are not passed to slave.
          As it was explained in this perfect comment it appears that Jenkins "Environment Variables" are not in fact environment variables - they should be called "Custom Jenkins Slave Parameters".
          As you could see here there is no variable called JAVA_VERSION among these so called "Environment Variables" (though they are not environment variables).
          So in order to get this fixed, you should define JAVA_VERSION variable using EnvInject plugin to get it injected into slave environment.
          See also related issues at StackOverflow:
          http://stackoverflow.com/questions/5818403/jenkins-hudson-environment-variables
          http://stackoverflow.com/questions/10625259/how-to-set-environment-variables-in-jenkins
          I guess it should fix the issue.
          Let me know if it does not.

          Dmitry Danilson added a comment - - edited Note that the variable in the file name was not expanded properly. Looks like it is the root of the issue: environment variables are not passed to slave. As it was explained in this perfect comment it appears that Jenkins "Environment Variables" are not in fact environment variables - they should be called "Custom Jenkins Slave Parameters". As you could see here there is no variable called JAVA_VERSION among these so called "Environment Variables" (though they are not environment variables). So in order to get this fixed, you should define JAVA_VERSION variable using EnvInject plugin to get it injected into slave environment. See also related issues at StackOverflow: http://stackoverflow.com/questions/5818403/jenkins-hudson-environment-variables http://stackoverflow.com/questions/10625259/how-to-set-environment-variables-in-jenkins I guess it should fix the issue. Let me know if it does not.

            gbois Gregory Boissinot
            eguess74 eguess74
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: