0

I'm having trouble compiling code which has a maven dependency on jline-0.9.94. Specifically, I'm compiling Groovy 1.7.6 using its default Ant target and getting the following error:

[...]
-banner:
     [echo] Java Runtime Environment version: 1.6.0_22
     [echo] Java Runtime Environment vendor: Apple Inc.
     [echo] Ant version: Apache Ant version 1.7.1 compiled on June 27 2008
     [echo] Operating system name: Mac OS X
     [echo] Operating system architecture: x86_64
     [echo] Operating system version: 10.6.6
     [echo] Base directory: /Users/ldhanson2/tmp/groovy-1.7.6
     [echo] Java Home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
[...]
-stagedcompile-groovy:
  [groovyc] Compiling 166 source files to /Users/ldhanson2/tmp/groovy-1.7.6/target/classes
  [groovyc] org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
  [groovyc] Compile error during compilation with javac.
  [groovyc] /Users/ldhanson2/tmp/groovy-1.7.6/src/main/groovy/ui/InteractiveShell.java:222: cannot find symbol
  [groovyc] symbol  : method setDefaultPrompt(java.lang.String)
  [groovyc] location: class jline.ConsoleReader
  [groovyc]         reader.setDefaultPrompt("groovy> ");
  [groovyc]               ^

The jline dependency is correctly resolved, but strangely the setDefaultPrompt method does not appear to be present in the jar:

$ javap -classpath target/lib/compile/jline-0.9.94.jar jline.ConsoleReader | grep setDefaultPrompt
$

(Other methods appear missing from the javap output as well, but setDefaultPrompt is the one breaking my build.)

I've tried wiping out jline from my local maven repository and trying again, to no avail. I've also checked the jline jarfile from Maven Central as well as a mirror with the same results.

Oddly, I can copy the jar file to a different machine (a Sun) and perform the exact same steps and I see the setDefaultPrompt method in the jar file as expected. Others have successfully performed the same steps on a Mac as well.

What could be happening on my machine which would prevent the Java toolchain from seeing methods contained in the jar file?

linuxbuild
  • 15,843
  • 6
  • 60
  • 87
Lyle
  • 3,724
  • 3
  • 25
  • 25
  • I have this exact same problem with the jline jar under Snow Leopard. Did you ever find the answer? – Scott Apr 02 '11 at 23:39

3 Answers3

0

You must have different versions of the JAR file.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • I can copy the exact file to a different machine and am then able to see the missing methods. I've edited my question to spell this out. – Lyle Jan 11 '11 at 09:34
0

Not reproducible on my Mac 10.5.8 with java 1.5.0_13

If you extract jline-0.9.94.jar and read its META-INF/MANIFEST.MF then you may find that this jar was compiled by java 1.4.2_16:

 Manifest-Version: 1.0
 Archiver-Version: Plexus Archiver
 Created-By: Apache Maven
 Built-By: jason
 Build-Jdk: 1.4.2_16

JRE is well backward compatible, but a distance between your 1.6.0_22 and 1.4.2_16 is very big.

So, I suppose you to recompile jline from source code.

linuxbuild
  • 15,843
  • 6
  • 60
  • 87
  • I've recompiled jline from source (with JDK 1.6.0_22) with the same result - javap does not see all of the methods present in the JAR. – Lyle Feb 03 '11 at 18:20
0

I had the same problem on my machine (compiling JRuby, rather than Groovy).

The solution to my problem was that I discovered an ancient jline jar at /Library/Java/Extensions/jline-0_9_5.jar, so I nuked it and replaced it with a more modern version.

Scott
  • 17,127
  • 5
  • 53
  • 64
  • Aha! Apparently that directory is always added to the classpath, even before the one you specify for javap. So I wasn't actually seeing the javap output for the jar file I thought I was inspecting. Sneaky. I verified this by adding an -extdirs option of /dev/null to stop javap from adding /Library/Jar/Extensions, at which point I can see the actual content of the jline version I'm looking at. – Lyle Apr 04 '11 at 14:25
  • Yes, that makes sense; I was using javap to verify too. I agree that it's totally sneaky. Seems a little pointless having the classpath option if it doesn't override the shell and gives misleading results. This issue drove me crazy! I diagnosed it by running a 2 line program the output the class location: URL location = ConsoleReader.class.getProtectionDomain().getCodeSource().getLocation(); – Scott Apr 04 '11 at 14:44