Can't use Java 6 classpath wildcards

It seems to me that this issue is still present in groovy 1.6-RC3.
Is it supposed to be this way?

Yes, there is no support for this currently though it would be good to add.

Any update on when this might be available? It's quite painful having to manually build classpath strings before invoking Groovy.

I made it a blocker for 1.8-beta-1, which means it will be in there unless something strange happens.

Thanks Jochen. Could GROOVY-3781 be considered as part of this? It seems like JVM command line parameter handling in general needs a bit of TLC.

Patch presented on user mailing list from saltnlight5@gmail.com:

D:/source/groovy/GROOVY_1_7_0
$ svn diff "src\main\org\codehaus\groovy\tools\LoaderConfiguration.java"
Index: src/main/org/codehaus/groovy/tools/LoaderConfiguration.java
===================================================================
--- src/main/org/codehaus/groovy/tools/LoaderConfiguration.java (revision
19114)
+++ src/main/org/codehaus/groovy/tools/LoaderConfiguration.java (working
copy)
@@ -304,9 +304,21 @@
      * @see java.io.File#pathSeparator
      */
     public void addClassPath(String path) {
-        String[] paths = path.split(File.pathSeparator);
+       String[] paths = path.split(File.pathSeparator);
         for (int i = 0; i < paths.length; i++) {
-            addFile(new File(paths[i]));
+               String cpPath = paths[i];
+               // Check to support wild card classpath
+               if (cpPath.endsWith("*")) {
+                       File dir = new File(cpPath.substring(0,
cpPath.length() - 1));
+                       File[] files = dir.listFiles();
+                       if (files != null) {
+                               for (int j = 0; j < files.length; j++) {
+                               addFile(files[j]);
+                               }
+                       }
+               } else {
+                       addFile(new File(cpPath));
+               }
         }
     }

Paul, has this patch been applied and tested?

Not tested or added yet. I wanted to check whether there was some code hidden in core Java somewhere that did this or whether we were forced to do it by hand as per patch.

Of course the flip side is that the patch would work on Java 1.5 too.

I think also, we need to check only for files ending in '.jar' (probably case insensitive) not all files as per current state of patch. Java also does this earlier than proposed patch. In its case, the java.class.path system property will contain the found jar files - no wildcard anymore.

Patch applied to trunk and 1_7_X branch (modified from saltnlight5 - thanks!)

This is saltnlight5, and I am glad I can help.

I still have this issue on 1.7.3 on Linux (Ubuntu Lucid).

I went back to 1.7.0 and it was still the same... the error message is really misleading - wasted a lot of time on it last night, glad I know what it is now so can at least work around it - have just put something like this

for x in `ls lib/*.jar`
do
libpath=$x:$libpath
done

in shellscript that starts groovy (using $libpath instead of wildcard after -cp in call to groovy)

btw - the error I get if I try and use wildcard is something like this:

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
/home/dalts/tmp/archiver/scripts/lib/bcprov-jdk14-138.jar: 1: unexpected char: 0x3 @ line 1, column 3.
   PK%Ug7META-INF/MANIFEST.MF��Y��Z�.|

Failing on the 2nd jar in the directory I believe.

Still having this issue on Groovy 1.8.0 with JDK 1.6 ... Groovy complaints on second JAR in directory:

groovy -cp /home/novoj/Prototypes/groovyScripts/lib/* cz/novoj/infrastructure/groovy/InfrastructureScriptInvoker.groovy

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
/home/novoj/Prototypes/groovyScripts/lib/spring-beans-3.0.5.RELEASE.jar: 1: unexpected char: 0x3 @ line 1, column 3.
PK
^

1 error