-
Bug
-
Resolution: Fixed
-
Critical
-
None
-
CentoOS 5 Linux master, assorted slaves
SEVERE: Failed to record SCM polling for hudson.maven.MavenModuleSet@1118b490[testing-parent-trunk] java.lang.IllegalArgumentException: Null value not allowed as an environment variable: POM_PACKAGING at hudson.EnvVars.put(EnvVars.java:356) at hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:194) at hudson.scm.SubversionSCM.compareRemoteRevisionWith(SubversionSCM.java:1235) at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356) at hudson.scm.SCM.poll(SCM.java:373) at hudson.model.AbstractProject._poll(AbstractProject.java:1584) at hudson.model.AbstractProject.poll(AbstractProject.java:1493) at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:456) at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:485) at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) 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:619)
- is blocking
-
JENKINS-18272 Expose key maven properties (such as GAV IDs) as build variables
-
- Resolved
-
[JENKINS-21279] java.lang.IllegalArgumentException: Null value not allowed as an environment variable: POM_PACKAGING
Jeremy Sullivan
added a comment - I resolved this by deleting all of the modules of the failing builds. The module location (and therefor the pom.xml) didn't exist in the file system.
I'm not really sure why deleting the module forced a version control update and not deleting everything in the workspace but it did.
Jeremy Sullivan
added a comment - I resolved this by deleting all of the modules of the failing builds. The module location (and therefor the pom.xml) didn't exist in the file system.
I'm not really sure why deleting the module forced a version control update and not deleting everything in the workspace but it did. 
Tony Sweeney
added a comment - @Jeremy: I'm not sure I understand your workround. Could you be more precise about exactly what you did when "deleting all of the modules of the failing builds"?
Tony Sweeney
added a comment - @Jeremy: I'm not sure I understand your workround. Could you be more precise about exactly what you did when "deleting all of the modules of the failing builds"? Jeremy Sullivan
added a comment - Sure Tony,
In my maven builds there is a "modules" section under "configure" the issue was these modules pointed to a directory that didn't exist, and that's what it was trying to read the pom.xml from (so the pom.xml didn't exist either) and instead of throwing a file not found jenkins complains about POM_PACKAGING being null.
When I deleted a module, it forced jenkins to grab everything (including the pom) from version control again, and so pom.xml was present again and POM_PACKAGING wasn't null anymore.
Hope this helps.
Jeremy Sullivan
added a comment - Sure Tony,
In my maven builds there is a "modules" section under "configure" the issue was these modules pointed to a directory that didn't exist, and that's what it was trying to read the pom.xml from (so the pom.xml didn't exist either) and instead of throwing a file not found jenkins complains about POM_PACKAGING being null.
When I deleted a module, it forced jenkins to grab everything (including the pom) from version control again, and so pom.xml was present again and POM_PACKAGING wasn't null anymore.
Hope this helps. Tony Sweeney
added a comment - I still don't understand what you mean by "deleting a module". Are you simply wiping the build slave workspace, or are you making a change to some of the build configuration?
Tony Sweeney
added a comment - I still don't understand what you mean by "deleting a module". Are you simply wiping the build slave workspace, or are you making a change to some of the build configuration? Jeremy Sullivan
added a comment - No, neither. There is a dropdown menu by the module name that will allow you to delete it.
For the record, I tried to delete the workspace. It had no effect.
Jeremy Sullivan
added a comment - No, neither. There is a dropdown menu by the module name that will allow you to delete it.
For the record, I tried to delete the workspace. It had no effect. OK, I had to fiddle a bit, as the delete dropdown menu item gave me a 403 bad crumb error, but if instead I selected the configure dropdown for the module, there was an option to delete the module in the left hand menu, which worked fine. If you then list the modules belonging to the build, the module still shows as present, but the status ball is greyed out. Running the build causes the module to be reinstantiated. This is a pretty painful workround, as I have many dozens of Maven builds each with a handful or two of modules. Worse, I can't actually validate it in my test system, since I can't reproduce the error there. But if it works it's better than nothing...
Tony Sweeney
added a comment - - edited OK, I had to fiddle a bit, as the delete dropdown menu item gave me a 403 bad crumb error, but if instead I selected the configure dropdown for the module, there was an option to delete the module in the left hand menu, which worked fine. If you then list the modules belonging to the build, the module still shows as present, but the status ball is greyed out. Running the build causes the module to be reinstantiated. This is a pretty painful workround, as I have many dozens of Maven builds each with a handful or two of modules. Worse, I can't actually validate it in my test system, since I can't reproduce the error there. But if it works it's better than nothing... 
Marco Huber
added a comment - We have the same problem after installing Jenkins V 1.549. We copied our project from Hudson 1.398 into the new Jenkins instance, but all exisiting configurations break with this error.
Marco Huber
added a comment - We have the same problem after installing Jenkins V 1.549. We copied our project from Hudson 1.398 into the new Jenkins instance, but all exisiting configurations break with this error. 
Aapo Romu
added a comment - I was able to fix the problem by deleting rm -rf jenkins/jobs/project_name/modules/* and then restarting Jenkins. You should be able to script that easily if you have a lot of projects
Aapo Romu
added a comment - I was able to fix the problem by deleting rm -rf jenkins/jobs/project_name/modules/* and then restarting Jenkins. You should be able to script that easily if you have a lot of projects Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
src/main/java/hudson/maven/MavenModuleSetBuild.java
http://jenkins-ci.org/commit/maven-plugin/4bdfef299f07fabedcb43b902d5ddfc05d62f8cd
Log:
[FIXED JENKINS-21279]
Not sure packaging doesn't defeault to "jar", which seems to be the default, but being defensive.
Looks like https://github.com/jenkinsci/maven-plugin/commit/59afb8b94eade3b29de98103d914ec487c128814 could be the cause?
Is it just that POM_PACKAGING doesn't have a default? http://maven.apache.org/pom.html says it should default to JAR