jpackage-utils-1.7.5-21.fc18.x86_64 After last update groovy stopped working properly with classpath. For example the command: > groovy -cp .groovy/grapes/javax.servlet/servlet-api/jars/servlet-api-2.4.jar:.groovy/grapes/org.codehaus.groovy.modules.remote/remote-transport-http/jars/remote-transport-http-0.5.jar:.groovy/grapes/org.codehaus.groovy.modules.remote/remote-core/jars/remote-core-0.5.jar ws/JBDS/Grog/src/org/jboss/test/grog/server/GrogServer.groovy fails with: > /usr/bin/build-classpath: error: Could not find javax.servlet/servlet-api/jars/servlet-api-2.4.jar Java extension for this JVM >/usr/bin/build-classpath: error: Could not find .groovy/grapes/org.codehaus.groovy.modules.remote/remote-transport-http/jars/remote-transport-http-0.5.jar Java extension for this JVM >/usr/bin/build-classpath: error: Could not find ~/.groovy/grapes/org.codehaus.groovy.modules.remote/remote-core/jars/remote-core-0.5.jar Java extension for this JVM This is due to the fact build-classpath only searches for JARs in specific directories and makes it impossible to specify a full path. I found that adding the following in the beginning of do_find_jar() in /usr/share/java-utils/java-functions makes it work: > if [ -r "$extension.jar" ] ; then > echo "$extension.jar" > return 0 > fi btw after last update of groovy the @Grab functionality makes groovy freeze forever. I tried enabling debug log but nothing really looks strange in there. I've no idea what the issue is but groovy is simply unusable right now.
On line 78 on the groovy script I see this: if [ "$1" = "-cp" -o "$1" = "-classpath" -o "$1" = "--classpath" ] ; then ADDITIONAL_JARS="$(echo $2 | tr ':' ' ')" shift 2 fi The ADDITIONAL_JARS variable is used (if set) in the set_classpath function in /usr/share/java-utils/java-functions which in turn uses build-claspath. The intention of build-classpath is to look up jars in very specific locations. Since build-classpath is used in spec files in order to resolve the classpath and thus build against *system* jars, I don't think this is a jpackage-utils bug. The groovy script should get fixed instead. Reassigning to the groovy component. FWIW, this looks like a duplicate of bug 810885 to me.
I'm not sure it is a duplicate or related but for the record I see the problem with groovy-1.8.9-1.fc18.noarch
Created attachment 771195 [details] Groovy script patch to allow jar filenames in classpath arguments I've attached a patch with my proposed fix. I think this should solve the problem you're seeing. Passing a classpath on the command line or using the CLASSPATH environment variable should work correctly.
(In reply to Aleksandar Kostadinov from comment #0) > btw after last update of groovy the @Grab functionality makes groovy freeze > forever. I tried enabling debug log but nothing really looks strange in > there. I've no idea what the issue is but groovy is simply unusable right > now. I can confirm this issue, but downgrading groovy to 1.8.7-2 doesn't seem to solve the problem. Do you remember which version of groovy worked for you?
Sorry, I'm not sure about version. I usually use the @Grap annotation so perhaps didn't use -cp in a long time. I tried the patch proposed and it is working for me to specify classpath.
groovy-1.8.9-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/groovy-1.8.9-2.fc18
groovy-1.8.9-4.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/groovy-1.8.9-4.fc19
Package groovy-1.8.9-2.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing groovy-1.8.9-2.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-15012/groovy-1.8.9-2.fc18 then log in and leave karma (feedback).
Hello, the updated package improves the situation and IMO can go to fedora updates but still the mechanism starting groovy in fedora is flawed. To debug the unrelated bug 998815 I downloaded java from oracle and tried starting groovy with it. This means I set JAVA_HOME and PATH to point at the third party java installation and run groovy. The result is error: > $ groovy -cp .groovy/grapes/javax.servlet/servlet-api/jars/servlet-api-2.4.jar:.groovy/grapes/org.codehaus.groovy.modules.remote/remote-transport-http/jars/remote-transport-http-0.5.jar:.groovy/grapes/org.codehaus.groovy.modules.remote/remote-core/jars/remote-core-0.5.jar /home/avalon/ws/JBDS/Grog/src/org/jboss/test/grog/server/GrogServer.groovy > /usr/bin/build-classpath: error: Could not find ../../jvm/java/lib/tools Java extension for this JVM > /usr/bin/build-classpath: error: Some specified jars were not found > org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: > /home/avalon/ws/JBDS/Grog/src/org/jboss/test/grog/server/GrogServer.groovy: 25: unable to resolve class groovyx.remote.server.Receiver > @ line 25, column 1. > import groovyx.remote.server.Receiver; > ^ > > /home/avalon/ws/JBDS/Grog/src/org/jboss/test/grog/server/GrogServer.groovy: 24: unable to resolve class groovyx.remote.transport.http.RemoteControlHttpHandler > @ line 24, column 1. > import groovyx.remote.transport.http.RemoteControlHttpHandler; > ^ > > 2 errors
groovy-1.8.9-2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
groovy-1.8.9-4.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.