I have a Linux master on which a Groovy installation is defined, let's say on /home/jenkins/groovy. Some of my slaves are Windows on which that same Groovy installation is overriden to for example c:\tools\groovy.

The way the groovy plugin code works (https://github.com/jenkinsci/groovy-plugin/blob/master/src/main/java/hudson/plugins/groovy/Groovy.java line 86) is it asks the master for a Groovy installation and if it exists sets the GROOVY_HOME env var from that installation. It should ask the slave for the correct directory.

In the buildCommandLine() method the correct way to find the Groovy installation is used (forNode) but that is only used to find the executable and not to set the GROOVY_HOME var.

The wrong GROOVY_HOME results in
Exception in thread "main" java.lang.NoClassDefFoundError: org/codehaus/groovy/tools/GroovyStarter
Caused by: java.lang.ClassNotFoundException: org.codehaus.groovy.tools.GroovyStarter
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)

IMHO setting the GROOVY_HOME var is not necessary, the groovy bat or sh file does this correctly (see also http://6by9.wordpress.com/2011/01/31/why-you-should-never-set-groovy_home/). Even when setting GROOVY_HOME like it is now, it is done wrong.