-cp include in bash script startGroovy do not include all needed jars

I think the problem is actually with your installation and not the script. The script simply bootstraps the Groovy runtime system which then loads the jars in $GROOVY_HOME/lib. The change to the script that you propose is not and should not be needed.

Clearly we need to find out why you are having this problem but this issue will almost certainly have to be marked as "Won't Fix".

I agree. We need to find the error in your installation, because this exact setup usually works. btw, $GROOVY_HOME/conf/groovy-starter.conf contains the additional classpath entries, so you should maybe take a look at this. Maybe that file was modified or is even empty. In that case it won't work.

No further feedback. Assuming environmental problems have been solved. Please reopen if you have further problems.

I see the same behavior with a fresh install of the Groovy 1.5.5 RPM on a CentOS 5.1 system. I set GROOVY_HOME to be "/usr/share/java/groovy/" and when I run "groovy" I get the listed exception. The "groovy-starter.conf" file appears to be present (copy attached).

CMD> echo $GROOVY_HOME
/usr/share/java/groovy/

CMD> ls $GROOVY_HOME/conf/
groovy-starter.conf

CMD> groovy
java.lang.NoClassDefFoundError: org/apache/commons/cli/CommandLineParser
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
at java.lang.Class.getMethod0(Class.java:2670)
at java.lang.Class.getMethod(Class.java:1603)
at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:92)
at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:130)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.cli.CommandLineParser
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)
... 6 more

CMD> java -version
java version "1.6.0_05"
Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode)

After experimenting a bit I was able to work around the error by setting the path to the lib dir in "groovy-starter.conf" explicitly. I replaced:

load !

/lib/*.jar

with:

load /usr/share/java/groovy/lib/*.jar

after which Groovy runs properly.

What happens if you remove the trailing slash on GROOVY_HOME but leave the conf file in its original form?

On Windows we now remove the trailing slash if found (for both JAVA_HOME and GROOVY_HOME). I guess that would be the thing to do here too.

startGroovy now removes a trailing slash on GROOVY_HOME if it finds it. Tested on Ubuntu.

It did'nt work for me on RedHat. Maybe the patch is not released yet ?

The fix verson for this issue is 1.5.6 which is due for release in a few days time. You can try a snapshot here:
http://snapshots.dist.codehaus.org/groovy/

I don't see how to reopen this – However, I found that if GROOVY_HOME had a double slash in it there would be a similar failure.

e.g.

export HOME=/Users/david/
export GROOVY_HOME=$

/groovy-1.6-RC-3
export PATH=$

/bin:$

Results in the same NoClassDefFoundError .. The above makes GROOVY_HOME=/Users/david//groovy-1.6-RC-3 (note two slashes) and if I change HOME to not have its trailing slash then it works fine.

a trailing slash is one thing, but a double slash in between... I think we can't work around all possible usage errors... what we maybe could do is to test if GROOVY_HOME exists as file if set and to give an error message if it does not exist as file. That would resolve your issue. If you want to have that I suggest opening a new JIRA issue, a feature request.