groovy

Can't use Java 6 classpath wildcards

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: 1.1-beta-2
  • Fix Version/s: 1.7.1, 1.8-beta-1
  • Component/s: None
  • Labels:
    None
  • Environment:
    Java 6
  • Number of attachments :
    0

Description

I'm using wildcards in my Java classpath, as is supported (finally!) by Java 6. I'd like to have Groovy honor that kind of classpath, and not fail to resolve items that Java can resolve.
See, e.g., http://blogs.sun.com/mr/entry/class_path_wildcards_in_mustang

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Federico Pedemonte added a comment -

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

Show
Federico Pedemonte added a comment - It seems to me that this issue is still present in groovy 1.6-RC3. Is it supposed to be this way?
Hide
Permalink
Paul King added a comment -

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

Show
Paul King added a comment - Yes, there is no support for this currently though it would be good to add.
Hide
Permalink
Peter Monks added a comment -

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

Show
Peter Monks added a comment - Any update on when this might be available? It's quite painful having to manually build classpath strings before invoking Groovy.
Hide
Permalink
blackdrag blackdrag added a comment -

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

Show
blackdrag blackdrag added a comment - I made it a blocker for 1.8-beta-1, which means it will be in there unless something strange happens.
Hide
Permalink
Peter Monks added a comment -

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.

Show
Peter Monks added a comment - 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.
Hide
Permalink
Paul King added a comment -

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));
+               }
         }
     }
Show
Paul King added a comment - 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));
+               }
         }
     }
Hide
Permalink
blackdrag blackdrag added a comment -

Paul, has this patch been applied and tested?

Show
blackdrag blackdrag added a comment - Paul, has this patch been applied and tested?
Hide
Permalink
Paul King added a comment -

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.

Show
Paul King added a comment - 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.
Hide
Permalink
Paul King added a comment -

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

Show
Paul King added a comment - Of course the flip side is that the patch would work on Java 1.5 too.
Hide
Permalink
Paul King added a comment -

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.

Show
Paul King added a comment - 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.
Hide
Permalink
Paul King added a comment -

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

Show
Paul King added a comment - Patch applied to trunk and 1_7_X branch (modified from saltnlight5 - thanks!)
Hide
Permalink
Zemian Deng added a comment -

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

Show
Zemian Deng added a comment - This is saltnlight5, and I am glad I can help.
Hide
Permalink
Steve Dalton added a comment -

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)

Show
Steve Dalton added a comment - 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)
Hide
Permalink
Steve Dalton added a comment -

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&#65533;&#65533;Y&#65533;&#65533;Z&#65533;.|

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

Show
Steve Dalton added a comment - 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&#65533;&#65533;Y&#65533;&#65533;Z&#65533;.|
Failing on the 2nd jar in the directory I believe.
Hide
Permalink
Jan Novotný added a comment -

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

Show
Jan Novotný added a comment - 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

People

Vote (4)
Watch (6)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.