-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Linux
-
Powered by SuggestiMate
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.
[JENKINS-15779] Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
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>"?
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
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.
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?
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,
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] ------------------------------------------------------------------------
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.
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); + } } }
I also committed a change ( https://github.com/jenkinsci/ivy-plugin/commit/708cc3e1c1bb66fe1a7415e305f2f8b7eefa6d06 ) to the IvyBuild file which hopefully fixes the compile bug.
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"
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
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
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.
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).
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"?
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
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.
https://github.com/jenkinsci/ivy-plugin/compare/ivy-descriptors is the more useful link by the way.
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.
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!