Bug 982378 - new jpackage breaks groovy and custom classpath
new jpackage breaks groovy and custom classpath
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: groovy (Show other bugs)
18
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Matt Spaulding
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-08 16:51 EDT by Aleksandar Kostadinov
Modified: 2013-09-29 20:47 EDT (History)
7 users (show)

See Also:
Fixed In Version: groovy-1.8.9-4.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-29 20:42:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Groovy script patch to allow jar filenames in classpath arguments (441 bytes, patch)
2013-07-09 15:01 EDT, Matt Spaulding
no flags Details | Diff

  None (edit)
Description Aleksandar Kostadinov 2013-07-08 16:51:47 EDT
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.
Comment 1 Severin Gehwolf 2013-07-09 05:33:51 EDT
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.
Comment 2 Aleksandar Kostadinov 2013-07-09 07:22:57 EDT
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
Comment 3 Matt Spaulding 2013-07-09 15:01:23 EDT
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.
Comment 4 Michal Srb 2013-07-11 02:57:19 EDT
(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?
Comment 5 Aleksandar Kostadinov 2013-07-11 03:34:14 EDT
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.
Comment 6 Fedora Update System 2013-08-18 19:26:02 EDT
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
Comment 7 Fedora Update System 2013-08-18 19:26:54 EDT
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
Comment 8 Fedora Update System 2013-08-19 17:28:36 EDT
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).
Comment 9 Aleksandar Kostadinov 2013-08-20 03:41:36 EDT
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
Comment 10 Fedora Update System 2013-09-29 20:42:18 EDT
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.
Comment 11 Fedora Update System 2013-09-29 20:47:22 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.