GRECLIPSE
  1. GRECLIPSE
  2. GRECLIPSE-1168

Error on "Run As | Groovy Script" for script with class definition

    Details

    • Number of attachments :
      4

      Description

      The following script:

      Foo foo = new Foo()
      
      class Foo {
          int f
      }
      

      produces the following error to stderr when launched with "Run As | Groovy Script":

      Caught: java.lang.AbstractMethodError
      java.lang.AbstractMethodError
      
      1. ClassTest.launch
        2 kB
        Bob Tiernay
      2. groovy-error.tgz
        2 kB
        Daniel Galán y Martins
      1. eclipse-versions.png
        75 kB
      2. groovy-eclipse-compile-bug.png
        77 kB

        Activity

        Hide
        Andrew Eisenberg added a comment -

        How exactly are you running this? What are you selecting when you do the Run As?

        I selected the script file, right-click -> Run As -> Groovy Script. And I had no problems.

        Show
        Andrew Eisenberg added a comment - How exactly are you running this? What are you selecting when you do the Run As? I selected the script file, right-click -> Run As -> Groovy Script. And I had no problems.
        Hide
        Bob Tiernay added a comment -

        Yes. Also launching with "Run As | Groovy Console" produces a similar error in groovyConsole, this time with a full stack trace:

        groovy> Test t = new Test() 
        groovy> println t 
        groovy> class Test { 
        groovy>     int f 
        groovy> } 
         
        Exception thrown
        4-Aug-2011 7:50:58 AM org.codehaus.groovy.runtime.StackTraceUtils sanitize
        WARNING: Sanitizing stacktrace:
        java.lang.AbstractMethodError
        	at org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:266)
        	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:123)
        	at org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:366)
        	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1058)
        	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:50)
        	at org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:174)
        	at org.codehaus.groovy.control.CompilationUnit$13.call(CompilationUnit.java:763)
        	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:957)
        	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:542)
        	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:520)
        	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:497)
        	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:306)
        	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:287)
        	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:731)
        	at groovy.lang.GroovyShell.run(GroovyShell.java:516)
        	at groovy.lang.GroovyShell.run(GroovyShell.java:172)
        	at groovy.lang.GroovyShell$run.call(Unknown Source)
        	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
        	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
        	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
        	at groovy.ui.Console$_runScriptImpl_closure16.doCall(Console.groovy:924)
        	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        	at java.lang.reflect.Method.invoke(Method.java:597)
        	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
        	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
        	at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
        	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:883)
        	at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
        	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:46)
        	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133)
        	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141)
        	at groovy.ui.Console$_runScriptImpl_closure16.doCall(Console.groovy)
        	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        	at java.lang.reflect.Method.invoke(Method.java:597)
        	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
        	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
        	at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
        	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:883)
        	at groovy.lang.Closure.call(Closure.java:410)
        	at groovy.lang.Closure.call(Closure.java:404)
        	at groovy.lang.Closure.run(Closure.java:488)
        	at java.lang.Thread.run(Thread.java:662)
        
        java.lang.AbstractMethodError
        

        See attached image as well.

        Show
        Bob Tiernay added a comment - Yes. Also launching with "Run As | Groovy Console" produces a similar error in groovyConsole , this time with a full stack trace: groovy> Test t = new Test() groovy> println t groovy> class Test { groovy> int f groovy> } Exception thrown 4-Aug-2011 7:50:58 AM org.codehaus.groovy.runtime.StackTraceUtils sanitize WARNING: Sanitizing stacktrace: java.lang.AbstractMethodError at org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:266) at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:123) at org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:366) at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1058) at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:50) at org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:174) at org.codehaus.groovy.control.CompilationUnit$13.call(CompilationUnit.java:763) at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:957) at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:542) at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:520) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:497) at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:306) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:287) at groovy.lang.GroovyShell.parseClass(GroovyShell.java:731) at groovy.lang.GroovyShell.run(GroovyShell.java:516) at groovy.lang.GroovyShell.run(GroovyShell.java:172) at groovy.lang.GroovyShell$run.call(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124) at groovy.ui.Console$_runScriptImpl_closure16.doCall(Console.groovy:924) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233) at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:883) at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:46) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141) at groovy.ui.Console$_runScriptImpl_closure16.doCall(Console.groovy) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233) at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:883) at groovy.lang.Closure.call(Closure.java:410) at groovy.lang.Closure.call(Closure.java:404) at groovy.lang.Closure.run(Closure.java:488) at java.lang. Thread .run( Thread .java:662) java.lang.AbstractMethodError See attached image as well.
        Hide
        Bob Tiernay added a comment -

        Error in groovyConsole

        Show
        Bob Tiernay added a comment - Error in groovyConsole
        Hide
        Bob Tiernay added a comment -

        Also of note that if I run the same script in groovyConsole from the command line, this script works as expected. Both versions are 1.8.1

        Show
        Bob Tiernay added a comment - Also of note that if I run the same script in groovyConsole from the command line, this script works as expected. Both versions are 1.8.1
        Hide
        Bob Tiernay added a comment -

        Version info:

        Feature Id Version
        org.codehaus.groovy.jdt.patch 2.1.3.xx-20110729-1800-e37
        org.codehaus.groovy.eclipse.feature 2.5.2.xx-20110729-1800-e37
        org.codehaus.groovy17.feature 2.5.2.xx-20110729-1800-e37
        org.codehaus.groovy18.feature 2.5.2.xx-20110729-1800-e37
        Show
        Bob Tiernay added a comment - Version info: Feature Id Version org.codehaus.groovy.jdt.patch 2.1.3.xx-20110729-1800-e37 org.codehaus.groovy.eclipse.feature 2.5.2.xx-20110729-1800-e37 org.codehaus.groovy17.feature 2.5.2.xx-20110729-1800-e37 org.codehaus.groovy18.feature 2.5.2.xx-20110729-1800-e37
        Hide
        Bob Tiernay added a comment -

        Also of note, if I switch to version 1.7 of Groovy in the preferences and restart, it works. If I switch back to 1.8 and restart, it ceases to work. Note that this is the only project open in my workspace.

        Show
        Bob Tiernay added a comment - Also of note, if I switch to version 1.7 of Groovy in the preferences and restart, it works. If I switch back to 1.8 and restart, it ceases to work. Note that this is the only project open in my workspace.
        Hide
        Bob Tiernay added a comment -

        Also, if I "Run As | Java Application" it also works with 1.8 configured

        Show
        Bob Tiernay added a comment - Also, if I "Run As | Java Application" it also works with 1.8 configured
        Hide
        Andrew Eisenberg added a comment -

        I think this may have to do with your launch configuration. It may be that your script is compiled using Groovy 1.8, but the launch config tries to launch using groovy 1.7.

        Can you attach your launch configuration here? Do this by first saving the config to a file:

        Run As -> Run Configurations... -> <Choose_your_launch_config> -> Common and select "Shared file". Attach the file that was saved.

        Show
        Andrew Eisenberg added a comment - I think this may have to do with your launch configuration. It may be that your script is compiled using Groovy 1.8, but the launch config tries to launch using groovy 1.7. Can you attach your launch configuration here? Do this by first saving the config to a file: Run As -> Run Configurations... -> <Choose_your_launch_config> -> Common and select "Shared file". Attach the file that was saved.
        Hide
        Bob Tiernay added a comment -

        Launch configuration showing error condition

        Show
        Bob Tiernay added a comment - Launch configuration showing error condition
        Hide
        Andrew Eisenberg added a comment -

        Thanks for the attachment. I think I see the problem. There is a section in the launch configuration where the launched process's classpath is explicitly specified.

        <listAttribute key="org.eclipse.jdt.launching.CLASSPATH">
        <listEntry value="/local/btiernay/workspace/greclipse-test1/bin"/>
        <listEntry value="/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110729-1800-e37/lib/groovy-all-1.8.1.jar"/>
        <listEntry value="/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110729-1800-e37/lib/ivy-2.2.0.jar"/>
        <listEntry value="/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110729-1800-e37/lib/commons-cli-1.2.jar"/>
        <listEntry value="/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110729-1800-e37/lib/jline-0.9.94.jar"/>
        <listEntry value="/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110729-1800-e37/lib/servlet-api-2.4.jar"/>
        <listEntry value="/local/btiernay/.groovy/greclipse/global_dsld_support"/>
        <listEntry value="/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110729-1800-e37/plugin_dsld_support/"/>
        </listAttribute>
        

        If you remove that section from the launch configuration, it should work. If the CLASSPATH attribute is left unspecified, then a default one will be created.

        Please let me know if this works for you. It does for me.

        Show
        Andrew Eisenberg added a comment - Thanks for the attachment. I think I see the problem. There is a section in the launch configuration where the launched process's classpath is explicitly specified. <listAttribute key= "org.eclipse.jdt.launching.CLASSPATH" > <listEntry value= "/local/btiernay/workspace/greclipse-test1/bin" /> <listEntry value= "/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110729-1800-e37/lib/groovy-all-1.8.1.jar" /> <listEntry value= "/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110729-1800-e37/lib/ivy-2.2.0.jar" /> <listEntry value= "/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110729-1800-e37/lib/commons-cli-1.2.jar" /> <listEntry value= "/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110729-1800-e37/lib/jline-0.9.94.jar" /> <listEntry value= "/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110729-1800-e37/lib/servlet-api-2.4.jar" /> <listEntry value= "/local/btiernay/.groovy/greclipse/global_dsld_support" /> <listEntry value= "/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110729-1800-e37/plugin_dsld_support/" /> </listAttribute> If you remove that section from the launch configuration, it should work. If the CLASSPATH attribute is left unspecified, then a default one will be created. Please let me know if this works for you. It does for me.
        Hide
        Bob Tiernay added a comment -

        After making the recommended changes, my launch configuration now looks like:

        <?xml version="1.0" encoding="UTF-8" standalone="no"?>
        <launchConfiguration type="org.codehaus.groovy.eclipse.groovyScriptLaunchConfiguration">
        <listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_PATHS">
        <listEntry value="/greclipse-test1"/>
        </listAttribute>
        <listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_TYPES">
        <listEntry value="4"/>
        </listAttribute>
        <stringAttribute key="org.eclipse.jdt.launching.MAIN_TYPE" value="org.codehaus.groovy.tools.GroovyStarter"/>
        <stringAttribute key="org.eclipse.jdt.launching.PROGRAM_ARGUMENTS" value="--classpath &quot;${workspace_loc:/greclipse-test1}/src:${workspace_loc:/greclipse-test1}/bin&quot; --main groovy.ui.GroovyMain &quot;${resource_loc:/greclipse-test1/src/ClassTest.groovy}&quot;"/>
        <stringAttribute key="org.eclipse.jdt.launching.PROJECT_ATTR" value="greclipse-test1"/>
        <stringAttribute key="org.eclipse.jdt.launching.VM_ARGUMENTS" value="-Dgroovy.starter.conf=&quot;${groovy_home}/conf/groovy-starter.conf&quot; -Dgroovy.home=&quot;${groovy_home}&quot;"/>
        <stringAttribute key="org.eclipse.jdt.launching.WORKING_DIRECTORY" value="${workspace_loc:/greclipse-test1}"/>
        </launchConfiguration>
        

        This produces the same result with this single file groovy project with no other projects open and after a restart.

        Show
        Bob Tiernay added a comment - After making the recommended changes, my launch configuration now looks like: <?xml version= "1.0" encoding= "UTF-8" standalone= "no" ?> <launchConfiguration type= "org.codehaus.groovy.eclipse.groovyScriptLaunchConfiguration" > <listAttribute key= "org.eclipse.debug.core.MAPPED_RESOURCE_PATHS" > <listEntry value= "/greclipse-test1" /> </listAttribute> <listAttribute key= "org.eclipse.debug.core.MAPPED_RESOURCE_TYPES" > <listEntry value= "4" /> </listAttribute> <stringAttribute key= "org.eclipse.jdt.launching.MAIN_TYPE" value= "org.codehaus.groovy.tools.GroovyStarter" /> <stringAttribute key= "org.eclipse.jdt.launching.PROGRAM_ARGUMENTS" value= "--classpath &quot;${workspace_loc:/greclipse-test1}/src:${workspace_loc:/greclipse-test1}/bin&quot; --main groovy.ui.GroovyMain &quot;${resource_loc:/greclipse-test1/src/ClassTest.groovy}&quot;" /> <stringAttribute key= "org.eclipse.jdt.launching.PROJECT_ATTR" value= "greclipse-test1" /> <stringAttribute key= "org.eclipse.jdt.launching.VM_ARGUMENTS" value= "-Dgroovy.starter.conf=&quot;${groovy_home}/conf/groovy-starter.conf&quot; -Dgroovy.home=&quot;${groovy_home}&quot;" /> <stringAttribute key= "org.eclipse.jdt.launching.WORKING_DIRECTORY" value= "${workspace_loc:/greclipse-test1}" /> </launchConfiguration> This produces the same result with this single file groovy project with no other projects open and after a restart.
        Hide
        Bob Tiernay added a comment -

        Verified that the original attached launch configuration works in Helios with 2.5.2.xx-20110725-1700-e36

        Show
        Bob Tiernay added a comment - Verified that the original attached launch configuration works in Helios with 2.5.2.xx-20110725-1700-e36
        Hide
        Bob Tiernay added a comment -

        Also verified the original attached launch configuration works in Helios with 2.5.2.xx-20110729-1700-e36. So it appears to only be an issue on Indigo Release Build id: 20110615-0604 with 2.5.2.xx-20110729-1700-e36

        Show
        Bob Tiernay added a comment - Also verified the original attached launch configuration works in Helios with 2.5.2.xx-20110729-1700-e36. So it appears to only be an issue on Indigo Release Build id: 20110615-0604 with 2.5.2.xx-20110729-1700-e36
        Hide
        Bob Tiernay added a comment -

        Also note that I have no problems with running scripts with Indigo Release Build id: 20110615-0604 with 2.5.2.xx-20110729-1700-e36 that don't contain a class definition. The launch configurations are identical as well (less the script file configuration)

        Show
        Bob Tiernay added a comment - Also note that I have no problems with running scripts with Indigo Release Build id: 20110615-0604 with 2.5.2.xx-20110729-1700-e36 that don't contain a class definition. The launch configurations are identical as well (less the script file configuration)
        Hide
        Daniel Galán y Martins added a comment - - edited

        Hi, I have this problem using eclipse 3.7 Indigo (Build id: 20110615-0604), with a fresh installed groovy plugin. I run Ubuntu 11.04, Oracle JDK 1.6.0_25. Groovy Compiler 1.8.0.xx.20110628-1600-e37, the groovy pluginversions are added as screenshot (I was lazy).

        I added a sample code fragment, that breaks when launching in eclipse (script and console), but does not when using the command line via groovy sandbox/Greeter.groovy.

        package sandbox
        
        class Greeter {
        
        	 static void main(String[] args) {
        		def mygreeting = "Hello World"
        		println mygreeting
        	}
        
        }
        

        I attached a project with launcher configuration, to provide best possible reproducibility.

        Here is the complete stacktrace when run in console:

        groovy> package sandbox 
        groovy> class Greeter { 
        groovy>      static void main(String[] args) { 
        groovy>         def mygreeting = "Hello World" 
        groovy>         println mygreeting 
        groovy>     } 
        groovy> } 
         
        Exception thrown
        17.08.2011 13:08:16 org.codehaus.groovy.runtime.StackTraceUtils sanitize
        WARNUNG: Sanitizing stacktrace:
        java.lang.AbstractMethodError
        	at org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:266)
        	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:123)
        	at org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:366)
        	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1056)
        	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:50)
        	at org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:174)
        	at org.codehaus.groovy.control.CompilationUnit$13.call(CompilationUnit.java:763)
        	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:957)
        	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:542)
        	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:520)
        	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:497)
        	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:306)
        	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:287)
        	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:731)
        	at groovy.lang.GroovyShell.run(GroovyShell.java:516)
        	at groovy.lang.GroovyShell.run(GroovyShell.java:172)
        	at groovy.lang.GroovyShell$run.call(Unknown Source)
        	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
        	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
        	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
        	at groovy.ui.Console$_runScriptImpl_closure16.doCall(Console.groovy:910)
        	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        	at java.lang.reflect.Method.invoke(Method.java:597)
        	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
        	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
        	at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
        	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:885)
        	at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
        	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:46)
        	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133)
        	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141)
        	at groovy.ui.Console$_runScriptImpl_closure16.doCall(Console.groovy)
        	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        	at java.lang.reflect.Method.invoke(Method.java:597)
        	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
        	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
        	at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
        	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:885)
        	at groovy.lang.Closure.call(Closure.java:405)
        	at groovy.lang.Closure.call(Closure.java:399)
        	at groovy.lang.Closure.run(Closure.java:483)
        	at java.lang.Thread.run(Thread.java:662)
        
        java.lang.AbstractMethodError
        
        Show
        Daniel Galán y Martins added a comment - - edited Hi, I have this problem using eclipse 3.7 Indigo (Build id: 20110615-0604), with a fresh installed groovy plugin. I run Ubuntu 11.04, Oracle JDK 1.6.0_25. Groovy Compiler 1.8.0.xx.20110628-1600-e37, the groovy pluginversions are added as screenshot (I was lazy). I added a sample code fragment, that breaks when launching in eclipse (script and console), but does not when using the command line via groovy sandbox/Greeter.groovy . package sandbox class Greeter { static void main( String [] args) { def mygreeting = "Hello World" println mygreeting } } I attached a project with launcher configuration, to provide best possible reproducibility. Here is the complete stacktrace when run in console: groovy> package sandbox groovy> class Greeter { groovy> static void main( String [] args) { groovy> def mygreeting = "Hello World" groovy> println mygreeting groovy> } groovy> } Exception thrown 17.08.2011 13:08:16 org.codehaus.groovy.runtime.StackTraceUtils sanitize WARNUNG: Sanitizing stacktrace: java.lang.AbstractMethodError at org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:266) at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:123) at org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:366) at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1056) at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:50) at org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:174) at org.codehaus.groovy.control.CompilationUnit$13.call(CompilationUnit.java:763) at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:957) at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:542) at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:520) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:497) at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:306) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:287) at groovy.lang.GroovyShell.parseClass(GroovyShell.java:731) at groovy.lang.GroovyShell.run(GroovyShell.java:516) at groovy.lang.GroovyShell.run(GroovyShell.java:172) at groovy.lang.GroovyShell$run.call(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124) at groovy.ui.Console$_runScriptImpl_closure16.doCall(Console.groovy:910) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233) at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:885) at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:46) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141) at groovy.ui.Console$_runScriptImpl_closure16.doCall(Console.groovy) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233) at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:885) at groovy.lang.Closure.call(Closure.java:405) at groovy.lang.Closure.call(Closure.java:399) at groovy.lang.Closure.run(Closure.java:483) at java.lang. Thread .run( Thread .java:662) java.lang.AbstractMethodError
        Hide
        Andrew Eisenberg added a comment -

        Have you tried deleting the launcher and creating a new one?

        Show
        Andrew Eisenberg added a comment - Have you tried deleting the launcher and creating a new one?
        Hide
        Daniel Galán y Martins added a comment -

        Yup - deleted, and new started (which creates a new launch configuration). Unfortunatly it didn't helped.

        Show
        Daniel Galán y Martins added a comment - Yup - deleted, and new started (which creates a new launch configuration). Unfortunatly it didn't helped.
        Hide
        Andrew Eisenberg added a comment -

        Open up the Preferences -> Groovy -> Compiler page. Are you using Groovy 1.7 or 1.8?

        Your problem is that there is a compiler mismatch problem happening somewhere. We just need to find out what is causing it.

        Show
        Andrew Eisenberg added a comment - Open up the Preferences -> Groovy -> Compiler page. Are you using Groovy 1.7 or 1.8? Your problem is that there is a compiler mismatch problem happening somewhere. We just need to find out what is causing it.
        Hide
        Daniel Galán y Martins added a comment -

        Groovy Compiler 1.8.0.xx.20110628-1600-e37. But I tried the "Switch to 1.7" too, without success (even with 1.7 the problem occurs).

        Show
        Daniel Galán y Martins added a comment - Groovy Compiler 1.8.0.xx.20110628-1600-e37. But I tried the "Switch to 1.7" too, without success (even with 1.7 the problem occurs).
        Hide
        Andrew Eisenberg added a comment -

        Let's try to get around the problem with your compiler switching for now. I know other people who have had a problem with compiler switching on recent builds and I have a fix for that, but the groovy-eclipse svn repo is closed for commits, so I can't create a build for that right now.

        I'm guessing that you want to use version 1.8, so do this:

        1. shut down eclipse
        2. open the file ..../eclipse/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info
        3. make a backup of this file.
        4. look for the two lines that start with org.codehaus.eclipse. There should be 2 entries, one for 1.7 and another for 1.8.
        5. Delete the 1.7 entry (or delete the 1.8 entry if you want to use 1.7)
        6. restart eclipse and you should be using 1.8 with no chance of switching back to 1.7 (without editing the bundles.info file).
        7. Full build of your project
        8. delete the old launch configuration
        9. Launch as a groovy script

        Hopefully, this should get you launching again. If not, could you try launching as a Java application?

        Show
        Andrew Eisenberg added a comment - Let's try to get around the problem with your compiler switching for now. I know other people who have had a problem with compiler switching on recent builds and I have a fix for that, but the groovy-eclipse svn repo is closed for commits, so I can't create a build for that right now. I'm guessing that you want to use version 1.8, so do this: shut down eclipse open the file ..../eclipse/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info make a backup of this file. look for the two lines that start with org.codehaus.eclipse. There should be 2 entries, one for 1.7 and another for 1.8. Delete the 1.7 entry (or delete the 1.8 entry if you want to use 1.7) restart eclipse and you should be using 1.8 with no chance of switching back to 1.7 (without editing the bundles.info file). Full build of your project delete the old launch configuration Launch as a groovy script Hopefully, this should get you launching again. If not, could you try launching as a Java application?
        Hide
        Bob Tiernay added a comment -

        Okay, so I've been able to narrow the problem down while using "Run As > Groovy Console". When I capture the process via ps I get:

        /usr/lib/jvm/java-6-sun-1.6.0.26/bin/java -Dgroovy.starter.conf=/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37//conf/groovy-starter.conf -Dgroovy.home=/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/ -Dfile.encoding=UTF-8 -classpath /local/btiernay/workspace/greclipse-test/bin:/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/lib/groovy-all-1.8.1.jar:/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/lib/ivy-2.2.0.jar:/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/lib/commons-cli-1.2.jar:/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/lib/jline-0.9.94.jar:/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/lib/servlet-api-2.4.jar:/local/btiernay/.groovy/greclipse/global_dsld_support:/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/plugin_dsld_support/ org.codehaus.groovy.tools.GroovyStarter --classpath /local/btiernay/workspace/greclipse-test/src:/local/btiernay/workspace/greclipse-test/bin --main groovy.ui.Console /local/btiernay/workspace/greclipse-test/src/com/oanda/bi/groovy/ClassTest.groovy
        

        This launches a groovyConsole which produces the same abstract method error. If I remove the following from the line, the problem goes away:

         -Dgroovy.starter.conf=/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37//conf/groovy-starter.conf
        

        The contents of this file is:

        ##############################################################################
        ##                                                                          ##
        ##  Groovy Classloading Configuration                                       ##
        ##                                                                          ##
        ##############################################################################
        
        ##
        ## $Revision: 9225 $ $Date: 2007-11-16 06:17:45 +1000 (Fri, 16 Nov 2007) $
        ##
        ## Note: do not add classes from java.lang here. No rt.jar and on some
        ##       platforms no tools.jar
        ##
        ## See http://groovy.codehaus.org/api/org/codehaus/groovy/tools/LoaderConfiguration.html
        ## for the file format
        
            # load required libraries
            load !{groovy.home}/lib/*.jar
        
            # load user specific libraries
            load !{user.home}/.groovy/lib/*.jar
        
            # tools.jar for ant tasks
            load ${tools.jar}
        ~                         
        

        Is it possible that one of these jars, such as tools.jar, is messing something up?

        Show
        Bob Tiernay added a comment - Okay, so I've been able to narrow the problem down while using "Run As > Groovy Console". When I capture the process via ps I get: /usr/lib/jvm/java-6-sun-1.6.0.26/bin/java -Dgroovy.starter.conf=/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37 //conf/groovy-starter.conf -Dgroovy.home=/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/ -Dfile.encoding=UTF-8 -classpath /local/btiernay/workspace/greclipse-test/bin:/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/lib/groovy-all-1.8.1.jar:/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/lib/ivy-2.2.0.jar:/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/lib/commons-cli-1.2.jar:/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/lib/jline-0.9.94.jar:/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/lib/servlet-api-2.4.jar:/local/btiernay/.groovy/greclipse/global_dsld_support:/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/plugin_dsld_support/ org.codehaus.groovy.tools.GroovyStarter --classpath /local/btiernay/workspace/greclipse-test/src:/local/btiernay/workspace/greclipse-test/bin --main groovy.ui.Console /local/btiernay/workspace/greclipse-test/src/com/oanda/bi/groovy/ClassTest.groovy This launches a groovyConsole which produces the same abstract method error. If I remove the following from the line, the problem goes away: -Dgroovy.starter.conf=/opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37 //conf/groovy-starter.conf The contents of this file is: ############################################################################## ## ## ## Groovy Classloading Configuration ## ## ## ############################################################################## ## ## $Revision: 9225 $ $Date: 2007-11-16 06:17:45 +1000 (Fri, 16 Nov 2007) $ ## ## Note: do not add classes from java.lang here. No rt.jar and on some ## platforms no tools.jar ## ## See http: //groovy.codehaus.org/api/org/codehaus/groovy/tools/LoaderConfiguration.html ## for the file format # load required libraries load !{groovy.home}/lib/*.jar # load user specific libraries load !{user.home}/.groovy/lib/*.jar # tools.jar for ant tasks load ${tools.jar} ~ Is it possible that one of these jars, such as tools.jar , is messing something up?
        Hide
        Bob Tiernay added a comment -

        Okay, so it looks as though it's the {{load !

        {groovy.home}

        /lib/*.jar}} statement.

        Show
        Bob Tiernay added a comment - Okay, so it looks as though it's the {{load ! {groovy.home} /lib/*.jar}} statement.
        Hide
        Bob Tiernay added a comment -

        Interestingly, if I create the following script:

        println 1
        

        in my groovy 1.8.1 groovyConsole, and inspect the AST, I get:

        this.println(1)
        public class script1313714377542 extends groovy.lang.Script { 
        
            public script1313714377542() {
            }
        
            public script1313714377542(groovy.lang.Binding context) {
                super.setBinding(context)
            }
        
            public static void main(java.lang.String[] args) {
                org.codehaus.groovy.runtime.InvokerHelper.runScript(script1313714377542, args)
            }
        
            public java.lang.Object run() {
                this.println(1)
            }
        
            public java.lang.Object this$dist$invoke$3(java.lang.String name, java.lang.Object args) {
                return this."$name"(* args )
            }
        
            public void this$dist$set$3(java.lang.String name, java.lang.Object value) {
                this ."$name" = value 
            }
        
            public java.lang.Object this$dist$get$3(java.lang.String name) {
                return this ."$name"
            }
        
        }
        

        When I perform the same operation with the greclipse groovyConsole I get:

        import groovypp.concurrent.*
        import java.util.concurrent.*
        
        return this.println(1)
        public class script1313714393418 extends groovy.lang.Script { 
        
            private static org.codehaus.groovy.reflection.ClassInfo $staticClassInfo 
            public static transient boolean __$stMC 
            public static long __timeStamp 
            public static long __timeStamp__239_neverHappen1313714393464 
        
            public script1313714393418() {
            }
        
            public script1313714393418(groovy.lang.Binding context) {
                super.setBinding(context)
            }
        
            public static void main(java.lang.String[] args) {
                org.codehaus.groovy.runtime.InvokerHelper.runScript(script1313714393418, args)
            }
        
            public java.lang.Object run() {
                return this.println(1)
            }
        
            public java.lang.Object this$dist$invoke$3(java.lang.String name, java.lang.Object args) {
                return this."$name"(* args )
            }
        
            public void this$dist$set$3(java.lang.String name, java.lang.Object value) {
                this ."$name" = value 
            }
        
            public java.lang.Object this$dist$get$3(java.lang.String name) {
                return this ."$name"
            }
        
            protected groovy.lang.MetaClass $getStaticMetaClass() {
            }
        
            static static { 
                __timeStamp__239_neverHappen1313714393464 = 0
                __timeStamp = 1313714393464
            }
        
        }
        

        Notice how this includes imports from groovy++. I'm not sure where those are coming from and they are not on the classpath.

        Show
        Bob Tiernay added a comment - Interestingly, if I create the following script: println 1 in my groovy 1.8.1 groovyConsole, and inspect the AST, I get: this .println(1) public class script1313714377542 extends groovy.lang.Script { public script1313714377542() { } public script1313714377542(groovy.lang.Binding context) { super .setBinding(context) } public static void main(java.lang. String [] args) { org.codehaus.groovy.runtime.InvokerHelper.runScript(script1313714377542, args) } public java.lang. Object run() { this .println(1) } public java.lang. Object this $dist$invoke$3(java.lang. String name, java.lang. Object args) { return this . "$name" (* args ) } public void this $dist$set$3(java.lang. String name, java.lang. Object value) { this . "$name" = value } public java.lang. Object this $dist$get$3(java.lang. String name) { return this . "$name" } } When I perform the same operation with the greclipse groovyConsole I get: import groovypp.concurrent.* import java.util.concurrent.* return this .println(1) public class script1313714393418 extends groovy.lang.Script { private static org.codehaus.groovy.reflection.ClassInfo $staticClassInfo public static transient boolean __$stMC public static long __timeStamp public static long __timeStamp__239_neverHappen1313714393464 public script1313714393418() { } public script1313714393418(groovy.lang.Binding context) { super .setBinding(context) } public static void main(java.lang. String [] args) { org.codehaus.groovy.runtime.InvokerHelper.runScript(script1313714393418, args) } public java.lang. Object run() { return this .println(1) } public java.lang. Object this $dist$invoke$3(java.lang. String name, java.lang. Object args) { return this . "$name" (* args ) } public void this $dist$set$3(java.lang. String name, java.lang. Object value) { this . "$name" = value } public java.lang. Object this $dist$get$3(java.lang. String name) { return this . "$name" } protected groovy.lang.MetaClass $getStaticMetaClass() { } static static { __timeStamp__239_neverHappen1313714393464 = 0 __timeStamp = 1313714393464 } } Notice how this includes imports from groovy++. I'm not sure where those are coming from and they are not on the classpath.
        Hide
        Bob Tiernay added a comment -

        Okay, so digging further I have discovered that removing /opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/lib/groovypp-0.4.248_1.8.0.jar fixes the original problem specified in this issue. There are probably some global ast transformations that are getting applied here that shouldn't be.

        Show
        Bob Tiernay added a comment - Okay, so digging further I have discovered that removing /opt/eclipse-3.7/plugins/org.codehaus.groovy_1.8.1.xx-20110811-2200-e37/lib/groovypp-0.4.248_1.8.0.jar fixes the original problem specified in this issue. There are probably some global ast transformations that are getting applied here that shouldn't be.
        Hide
        Andrew Eisenberg added a comment -

        Thanks for digging into this. I was not aware that everything from groovy.home was automatically added to your script's runtime classpath. I was able to reproduce the little test you did with the groovy console.

        We need to move all non-essential jars out of that folder into a new location where they will not conflict with running scripts.

        I'm still not sure why I was not seeing the same problem that you were.

        Show
        Andrew Eisenberg added a comment - Thanks for digging into this. I was not aware that everything from groovy.home was automatically added to your script's runtime classpath. I was able to reproduce the little test you did with the groovy console. We need to move all non-essential jars out of that folder into a new location where they will not conflict with running scripts. I'm still not sure why I was not seeing the same problem that you were.
        Hide
        Andrew Eisenberg added a comment -

        Daniel, I think that you are having a different problem, but it may be worth trying anyway. Can you try moving your groovypp jar to a new folder?

        Show
        Andrew Eisenberg added a comment - Daniel, I think that you are having a different problem, but it may be worth trying anyway. Can you try moving your groovypp jar to a new folder?
        Hide
        Daniel Galán y Martins added a comment - - edited

        Andrew, thanks for your instructions, I performed them as you told, but the problem still remains.
        I tried Bobs suggestion, and removed the groovypp-0.4.248_1.8.0.jar library, which seemed to work.
        So I'm taking this workaround for now, hopping that it won't break to much other things, until there is an official bugfix release.
        Thanks for your dedication on this topic!

        Show
        Daniel Galán y Martins added a comment - - edited Andrew, thanks for your instructions , I performed them as you told, but the problem still remains. I tried Bobs suggestion , and removed the groovypp-0.4.248_1.8.0.jar library, which seemed to work. So I'm taking this workaround for now, hopping that it won't break to much other things, until there is an official bugfix release. Thanks for your dedication on this topic!
        Hide
        Andrew Eisenberg added a comment -

        That's good that it turned out to be the same issue. I will implement the fix to move the groovypp jar from the /lib folder to the /extras folder. More jars may be moved there in order for the default classpath of scripts to not get too messy.

        Show
        Andrew Eisenberg added a comment - That's good that it turned out to be the same issue. I will implement the fix to move the groovypp jar from the /lib folder to the /extras folder. More jars may be moved there in order for the default classpath of scripts to not get too messy.
        Hide
        Andrew Eisenberg added a comment -

        I am tentatively closing this issue since I committed the change for removing the groovypp jar from the classpath of scripts.

        If you continue to have trouble executing scripts, please re-open.

        Show
        Andrew Eisenberg added a comment - I am tentatively closing this issue since I committed the change for removing the groovypp jar from the classpath of scripts. If you continue to have trouble executing scripts, please re-open.

          People

          • Assignee:
            Andrew Eisenberg
            Reporter:
            Bob Tiernay
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: