GRECLIPSE

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. File
    groovy-error.tgz
    17/Aug/11 6:09 AM
    2 kB
    Daniel Galán y Martins
  2. File
    ClassTest.launch
    04/Aug/11 1:49 PM
    2 kB
    Bob Tiernay
  1. groovy-eclipse-compile-bug.png
    77 kB
    04/Aug/11 6:55 AM
  2. eclipse-versions.png
    75 kB
    17/Aug/11 6:17 AM

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
Bob Tiernay added a comment -

Error in groovyConsole

Show
Bob Tiernay added a comment - Error in groovyConsole
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
Bob Tiernay added a comment -

Launch configuration showing error condition

Show
Bob Tiernay added a comment - Launch configuration showing error condition
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (1)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: