Hudson having problem with Subversion: hudson.model.Job.hasCascadingProject()Z

One day, a few of our Hudson jobs (but not all) started to have this error when executing.

FATAL: hudson.model.Job.hasCascadingProject()Z
java.lang.NoSuchMethodError: hudson.model.Job.hasCascadingProject()Z
 at hudson.scm.PerJobCredentialStore.getXmlFile(PerJobCredentialStore.java:137)
 at hudson.scm.PerJobCredentialStore.<init>(PerJobCredentialStore.java:58)
 at hudson.scm.SubversionSCM$DescriptorImpl.createAuthenticationProvider(SubversionSCM.java:1820)
 at hudson.scm.SubversionSCM$DescriptorImpl.getRepository(SubversionSCM.java:2069)
 at hudson.scm.SubversionSCM$DescriptorImpl.checkRepositoryPath(SubversionSCM.java:2039)
 at hudson.scm.SubversionSCM.repositoryLocationsNoLongerExist(SubversionSCM.java:2272)
 at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:748)
 at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:711)
 at hudson.model.AbstractProject.checkout(AbstractProject.java:1229)
 at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:507)
 at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:424)
 at hudson.model.Run.run(Run.java:1367)
 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
 at hudson.model.ResourceController.execute(ResourceController.java:88)
 at hudson.model.Executor.run(Executor.java:145)

This turns out to be at the Subversion check-out step:

You can click on "Update credentials" to go to a screen to enter in your credentials.  But you might get the following error:

HTTP ERROR 500

Problem accessing /hudson/job/PWS-OCDT/descriptorByName/hudson.scm.SubversionSCM/postCredential. Reason:

    hudson.model.Job.hasCascadingProject()Z

Caused by:

java.lang.NoSuchMethodError: hudson.model.Job.hasCascadingProject()Z
 at hudson.scm.PerJobCredentialStore.getXmlFile(PerJobCredentialStore.java:137)

At this point, check the file-system of your Hudson server.  Under <HUDSON_HOME>\jobs\<Job name> you may notice that compared to Jobs that are working, the problematic job does not have a "subversion.credentials" file.  Copy over this file as-is to the directory.  No Hudson re-start is necessary; just go back to the Dashboard and choose the problematic Job.  From this point, you should be able to choose "Update credentials" and work through the screens without getting an unhelpful

hudson.model.Job.hasCascadingProject()Z 

error.  FYI, this is Hudson ver. 2.1.2 and our Subversion server location changed, which may have caused this issue. 

Maven error "Cannot find wagon which supports the requested protocol: ftp" and Hudson

It is important to understand that Hudson comes bundled with Maven but you can also configure Hudson to use an external installation of Maven (Manage Hudson > Configure System > Maven 3 section).  When you add a Maven build step to your Job, you have the option to use the bundled Maven or your external installation.  However, the default is the bundled Maven. 

This can cause problems if you need additional classes required by your Maven plugins that are not automatically downloaded, e.g. FTP support for the Deploy Plugin or Wagon Plugin (http://mojo.codehaus.org/wagon-maven-plugin/).  That is, if you have dropped the required JAR into the "lib" sub-folder of your external Maven installation but the Job is configured to use the bundled Maven, you will continue to get "Cannot find wagon which supports the requested protocol: ftp" (in this case).

Changing default directory

Sometimes it is necessary to change the default directory of an application, e.g. when there are limitations to Profile Storage Space on your Windows machine.

Application	Configuration location	Details
Maven	<user directory>/.m2/settings.xml	Change where local repository is stored, e.g. <localRepository>C:\_LOCALdata\m2\repository</localRepository>
Jetty		You can change where WAR files are extracted to, e.g. by simply creating a directory named "work" in your Jetty distribution
Nexus	<Nexus web app directory>/webapp/WEB-INF/plexus.properties	Edit file and change the property "nexus-work"
Hudson	<Jetty directory>/etc/jetty.xml	According to Administering Hudson, you can add a HUDSON_HOME environment variable and re-start Jetty, but this didn't work for me.  However the second option did work, add e.g.:     <Call class="java.lang.System" name="setProperty">         <Arg>HUDSON_HOME</Arg>         <Arg>C:/_LOCALdata/SERVICES/hudson-home</Arg>     </Call>

Getting Groovy test cases to run with Maven

Groovy is excellent for writing test cases because of its brevity and meta-programming capabilities.  For example, a class that I was using to do integration testing called System.exit in its main method.  With Groovy I could re-define its main method so that I could continue running the rest of my test code:

        Launcher.metaClass.'static'.main = { String[] args ->
            delegate.programArguments = args
            delegate.init()
            delegate.run()
            // No more System.exit!
        }

However, to get Groovy test cases to run inside Maven (and outside of Eclipse) requires some tweaks.  First of all, you have to make Maven aware that there are Groovy test cases to execute, or else it won't even find them  The section "Configuring Maven2 to compile and run your Groovy tests" in the article Writing unit tests using Groovy is mostly correct but it is out-of-date.  If you use its Maven coordinates verbatim, you will have errors in your Maven output.

Error:  Execution default of goal org.codehaus.mojo.groovy:groovy-maven-plugin:1.0-beta-3:testCompile failed: An API incompatibility was encountered while executing org.codehaus.mojo.groovy:groovy-maven-plugin:1.0-beta-3:testCompile: java.lang.NoSuchMethodError: org.codehaus.plexus.PlexusContainer.hasChildContainer(Ljava/lang/String;)Z
This can be corrected by changing the coordinates of the Groovy Maven plugin to:              
<groupId>org.codehaus.mojo</groupId>
<artifactId>groovy-maven-plugin</artifactId>
<version>1.3</version>

Error:  Failed to execute goal org.codehaus.mojo:groovy-maven-plugin:1.3:testCompile ... Unknown type: METHOD_DEF
This can be caused by anonymous inner classes in the code.  Groovy for Java Programmers gives some suggestions for how to re-format your code so that Groovy can properly parse it and recognize an anonymous inner class definition, however these suggestions didn't work for me.  Anonymous inner class are a convenience so one can re-write the code to eliminate them.

Error:  initializationError(...): [Lorg/codehaus/groovy/runtime/callsite/CallSite;
You may only see one line in the Maven output which is not particularly helpful.  However, you can look at the detailed test output.  In Hudson, it would be at a location under HUDSON_HOME similar to jobs\<your job>\workspace\target\surefire-reports\  Looking here, you may see an error java.lang.NoClassDefFoundError: [Lorg/codehaus/groovy/runtime/callsite/CallSite;
To fix this, update your Groovy Maven run-time coordinates to:

<groupId>org.codehaus.groovy.maven.runtime</groupId>
<artifactId>gmaven-runtime-1.6</artifactId>
<version>1.0</version>
<scope>test</scope>

After all this, you should finally see your Groovy test executed in the Maven output.