groovy eclipse plugin

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

groovy eclipse plugin

louis foucart
Hi,

I like a lot Groovy so Ive done some work on the eclipse plugin the last two weeks.
Ive come up with some great functionalities like auto indentation, bracket matcher (highlight and auto add), folding and improved syntax higlithing. I also have auto completion for keywords.
I am working now on the auto completion and javadoc access which are the most important stuff in a code editor. But it is the trickiest as we need a true groovy model and/or a dom/ast model (complete with code access). So i am adapting the TreeAdapter to a true model copying the JDT but the Nodes classes from groovy are note allmighty.
After I will work on working copies of this model (with store) in order to have always this information (not only from the first compilation). Then use the reconciler of eclipse editors to update the model when the source code change.

I will be really pleased to follow the progress on the plugin and help with my work. For example the most simple part and from my point of view which add quite neafty capability is auto editing strategies. You just have to add five lines of code in GroovyConfiguration.java to have this ! Here it is :

/*
     * @see org.eclipse.jface.text.source.SourceViewerConfiguration#getAutoEditStrategies(org.eclipse.jface.text.source.ISourceViewer, java.lang.String)
     */
    public IAutoEditStrategy[] getAutoEditStrategies(ISourceViewer sourceViewer, String contentType) {
        String partitioning= getConfiguredDocumentPartitioning(sourceViewer);
        if (IJavaPartitions.JAVA_DOC.equals(contentType) || IJavaPartitions.JAVA_MULTI_LINE_COMMENT.equals(contentType))
            return new IAutoEditStrategy[] { new JavaDocAutoIndentStrategy(partitioning) };
        else if (IJavaPartitions.JAVA_STRING.equals(contentType))
            return new IAutoEditStrategy[] { new SmartSemicolonAutoEditStrategy(partitioning), new JavaStringAutoIndentStrategy(partitioning) };
        else if (IJavaPartitions.JAVA_CHARACTER.equals(contentType) || IDocument.DEFAULT_CONTENT_TYPE.equals(contentType))
            return new IAutoEditStrategy[] { new SmartSemicolonAutoEditStrategy(partitioning), new JavaAutoIndentStrategy(partitioning, getJavaProject()) };
        else
            return new IAutoEditStrategy[] { new JavaAutoIndentStrategy(partitioning, getJavaProject()) };
            //return new IAutoEditStrategy[] { new DefaultIndentLineAutoEditStrategy() };
    }

All classes used are directly from the JDT and work out from the box. There is also a method needed to access the current IJavaProject :

private IJavaProject getJavaProject() {
        ITextEditor editor= getEditor();
        if (editor == null)
            return null;
 
        IEditorInput input= editor.getEditorInput();
         
        if (input == null)
            return null;
 
        return  EditorUtility.getJavaProject(input);
    }

I think you dont have the getEditor() method but it is just an accessor.

There are some parts from the JDT we can directly reuse, others I had to tweak a lot.
To have bracket matcher and bracket auto completion is quite similar.

I have a question about licences. Since most part of the code here comes from the JDT, how does it work to take it in your code ?

Thanks for your attention, and great work to all !

Louis.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: groovy eclipse plugin

Scott Hickey-3
We can use all the help we can get with the plugin.
 
If you have things that are already working, I would love to get them incorporated into the plugin. I was starting on the semantic highlighting as well. I have started to look at the one build into the JDT Java editor but it sounds like you are further along than I am.
 
I am not sure how it works from a licensing standpoint to take chunks of code from the JDT Java editor and copy it into our plugin.
 
I am new to the project. Guillaume - should we create JIRA issues for these and attach patches to the issue? or should I apply patches and create JIRA issues as we run into actual bugs?
 
Scott


----- Original Message ----
From: louis foucart <[hidden email]>
To: [hidden email]
Sent: Wednesday, April 12, 2006 11:26:34 AM
Subject: [groovy-dev] groovy eclipse plugin

Hi,

I like a lot Groovy so Ive done some work on the eclipse plugin the last two weeks.
Ive come up with some great functionalities like auto indentation, bracket matcher (highlight and auto add), folding and improved syntax higlithing. I also have auto completion for keywords.
I am working now on the auto completion and javadoc access which are the most important stuff in a code editor. But it is the trickiest as we need a true groovy model and/or a dom/ast model (complete with code access). So i am adapting the TreeAdapter to a true model copying the JDT but the Nodes classes from groovy are note allmighty.
After I will work on working copies of this model (with store) in order to have always this information (not only from the first compilation). Then use the reconciler of eclipse editors to update the model when the source code change.

I will be really pleased to follow the progress on the plugin and help with my work. For example the most simple part and from my point of view which add quite neafty capability is auto editing strategies. You just have to add five lines of code in GroovyConfiguration.java to have this ! Here it is :

/*
     * @see org.eclipse.jface.text.source.SourceViewerConfiguration#getAutoEditStrategies(org.eclipse.jface.text.source.ISourceViewer, java.lang.String)
     */
    public IAutoEditStrategy[] getAutoEditStrategies(ISourceViewer sourceViewer, String contentType) {
        String partitioning= getConfiguredDocumentPartitioning(sourceViewer);
        if (IJavaPartitions.JAVA_DOC.equals(contentType) || IJavaPartitions.JAVA_MULTI_LINE_COMMENT.equals(contentType))
            return new IAutoEditStrategy[] { new JavaDocAutoIndentStrategy(partitioning) };
        else if (IJavaPartitions.JAVA_STRING.equals(contentType))
            return new IAutoEditStrategy[] { new SmartSemicolonAutoEditStrategy(partitioning), new JavaStringAutoIndentStrategy(partitioning) };
        else if (IJavaPartitions.JAVA_CHARACTER.equals(contentType) || IDocument.DEFAULT_CONTENT_TYPE.equals(contentType))
            return new IAutoEditStrategy[] { new SmartSemicolonAutoEditStrategy(partitioning), new JavaAutoIndentStrategy(partitioning, getJavaProject()) };
        else
            return new IAutoEditStrategy[] { new JavaAutoIndentStrategy(partitioning, getJavaProject()) };
            //return new IAutoEditStrategy[] { new DefaultIndentLineAutoEditStrategy() };
    }

All classes used are directly from the JDT and work out from the box. There is also a method needed to access the current IJavaProject :

private IJavaProject getJavaProject() {
        ITextEditor editor= getEditor();
        if (editor == null)
            return null;
 
        IEditorInput input= editor.getEditorInput();
         
        if (input == null)
            return null;
 
        return  EditorUtility.getJavaProject(input);
    }

I think you dont have the getEditor() method but it is just an accessor.

There are some parts from the JDT we can directly reuse, others I had to tweak a lot.
To have bracket matcher and bracket auto completion is quite similar.

I have a question about licences. Since most part of the code here comes from the JDT, how does it work to take it in your code ?

Thanks for your attention, and great work to all !

Louis.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: groovy eclipse plugin

Jochen Theodorou
Scott Hickey schrieb:
[...]
> I am not sure how it works from a licensing standpoint to take chunks of
> code from the JDT Java editor and copy it into our plugin.

good question!

> I am new to the project. Guillaume - should we create JIRA issues for
> these and attach patches to the issue? or should I apply patches and
> create JIRA issues as we run into actual bugs?

Please create issues, you don't have to add patches to them, but you
should create them to track work

bye blackdrag
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: groovy eclipse plugin

Guillaume Laforge
Administrator
Yup, I second Jochen, it's always better to create JIRA issues to
track the work being done on the Groovy codebase and its related
modules.
Moreover, it also helps me write the release notes ;-)

On 4/12/06, Jochen Theodorou <[hidden email]> wrote:

> Scott Hickey schrieb:
> [...]
> > I am not sure how it works from a licensing standpoint to take chunks of
> > code from the JDT Java editor and copy it into our plugin.
>
> good question!
>
> > I am new to the project. Guillaume - should we create JIRA issues for
> > these and attach patches to the issue? or should I apply patches and
> > create JIRA issues as we run into actual bugs?
>
> Please create issues, you don't have to add patches to them, but you
> should create them to track work
>
> bye blackdrag
>


--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: groovy eclipse plugin

Scott Hickey-3
I'll be sure to create JIRA issues for any new features. I will try to review the existing plugin issues as well; last time I glanced through them I thought some could be closed.

The JIRA issue form has a place for which version the issue applies to. I'm not sure what you want to me to put there. The plugin isn't being released like the core is and it is not in nearly as good of shape (yet).
 
Scott


----- Original Message ----
From: Guillaume Laforge <[hidden email]>
To: [hidden email]
Sent: Wednesday, April 12, 2006 3:56:30 PM
Subject: Re: [groovy-dev] groovy eclipse plugin

Yup, I second Jochen, it's always better to create JIRA issues to
track the work being done on the Groovy codebase and its related
modules.
Moreover, it also helps me write the release notes ;-)

On 4/12/06, Jochen Theodorou <[hidden email]> wrote:

> Scott Hickey schrieb:
> [...]
> > I am not sure how it works from a licensing standpoint to take chunks of
> > code from the JDT Java editor and copy it into our plugin.
>
> good question!
>
> > I am new to the project. Guillaume - should we create JIRA issues for
> > these and attach patches to the issue? or should I apply patches and
> > create JIRA issues as we run into actual bugs?
>
> Please create issues, you don't have to add patches to them, but you
> should create them to track work
>
> bye blackdrag
>


--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: groovy eclipse plugin

Guillaume Laforge
Administrator
On 4/13/06, Scott Hickey <[hidden email]> wrote:
>
> I'll be sure to create JIRA issues for any new features. I will try to
> review the existing plugin issues as well; last time I glanced through them
> I thought some could be closed.

Okay.
It's always good to do some spring cleaning ;-)

>  The JIRA issue form has a place for which version the issue applies to. I'm
> not sure what you want to me to put there. The plugin isn't being released
> like the core is and it is not in nearly as good of shape (yet).

Yeah, we haven't defined any roadmap of versions for the plugin.
So, either use the "current" or "target" Groovy release, or perhaps we
might try to configure JIRA to specify a specific versioning scheme
for that component.
But anyway, there's nothing critical there.

--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Groovy Monkey ( Eclipse )

James Ervin-2
In reply to this post by louis foucart
Hello,
  I recently (today) was trying to hack the Eclipse Monkey plugin to
support Groovy.  It looked rather straightforward as the Eclipse Monkey
plugin is not particulary complicated, it is just that it only supports
Java Script (yuck).

I changed it to recognize groovy extensions inside the monkey
subdirectories, that worked fine.  I then changed the RunMonkeyScript (
take a look at the source code for the Eclipse Monkey at
http://www.eclipse.org/dash ) to compile the groovy source, extract the
dom information at the top of the script, put in the variable bindings
and even got a requisite "Hello World" script to function.  This is
where the ease and fun ends however.

I wanted to port one of the example scripts called Find_System_Prints
to groovy.  It was rather straightforward, but when it came time to
reference one of the bound variables, in this case "resources", I got
the following error:

java.lang.NoClassDefFoundError: org/eclipse/dash/dom/resources/Resources
        at
gjdk.org.eclipse.dash.dom.resources.Resources_GroovyReflector.invoke(Unknown
Source)
        at groovy.lang.MetaMethod.invoke(MetaMethod.java:111)
        at
org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:636)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:345)
        at org.codehaus.groovy.runtime.Invoker.invokeMethod(Invoker.java:144)
        at
org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:104)
        at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethod(ScriptBytecodeAdapter.java:85)
        at FindSystemPrints.run(FindSystemPrints.gvy:15)
        at groovy.lang.GroovyShell.evaluate(GroovyShell.java:521)
        at groovy.lang.GroovyShell.evaluate(GroovyShell.java:462)
        at
org.eclipse.eclipsemonkey.RunMonkeyScript.runGroovyScript(RunMonkeyScript.java:97)
        at org.eclipse.eclipsemonkey.RunMonkeyScript.run(RunMonkeyScript.java:60)
        at
org.eclipse.eclipsemonkey.actions.RecreateMonkeyMenuAction$3.run(RecreateMonkeyMenuAction.java:158)
        at org.eclipse.jface.action.Action.runWithEvent(Action.java:499)
        at
org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:539)
        at
org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:488)
        at
org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:400)
        at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928)
        at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968)
        at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914)
        at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878)
        at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419)
        at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:143)
        at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95)
        at
org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78)
        at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92)
        at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68)
        at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:376)
        at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:169)
        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:589)
        at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336)
        at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
        at org.eclipse.core.launcher.Main.run(Main.java:977)
        at org.eclipse.core.launcher.Main.main(Main.java:952)

Basically it could not find the class.  Of course I did not give up at
this point, I tried using both the GroovyShell and GroovyClassLoader to
compile the script and the same problem recurred.  Here is the kicker,
if I write the groovy code to use reflection, the getMethod() call will
also fail.  If I iterate through the array of methods after calling
getMethods() and then invoke the object with that method object, it
works....

I am inclosing my little example script, the top part that is commented
out, will work, while the invocation of resources.filesMatching() fails.

I was hoping someone could point me in the right direction as to the
cause of this problem.  I know that the Eclipse (OSGi) classloader
model does violate the java classloader model, so I was thinking that I
might try an adapter classloader for the GroovyClassLoader, to have it
goto the bundle to get the class definition or I was wondering if there
might be a way to more properly wrap java objects for groovy ( I know
it shouldn't be the case )?  I did go through the stack trace and it
seems that there is a MetaClass and MetaMethod that get invoked that
use a reflector before the actual object is actually invoked.  Is there
a way to short circuit that or something?

  Thanks for your help,
  James E. Ervin, IV

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Groovy Monkey ( Eclipse )

James Ervin-2
Oops I forgot the script attachment.
James E. Ervin

Quoting [hidden email]:

> Hello,
>  I recently (today) was trying to hack the Eclipse Monkey plugin to
> support Groovy.  It looked rather straightforward as the Eclipse
> Monkey plugin is not particulary complicated, it is just that it only
> supports Java Script (yuck).
>
> I changed it to recognize groovy extensions inside the monkey
> subdirectories, that worked fine.  I then changed the RunMonkeyScript
> ( take a look at the source code for the Eclipse Monkey at
> http://www.eclipse.org/dash ) to compile the groovy source, extract
> the dom information at the top of the script, put in the variable
> bindings and even got a requisite "Hello World" script to function.  
> This is where the ease and fun ends however.
>
> I wanted to port one of the example scripts called Find_System_Prints
> to groovy.  It was rather straightforward, but when it came time to
> reference one of the bound variables, in this case "resources", I got
> the following error:
>
> java.lang.NoClassDefFoundError: org/eclipse/dash/dom/resources/Resources
> at
> gjdk.org.eclipse.dash.dom.resources.Resources_GroovyReflector.invoke(Unknown
> Source)
> at groovy.lang.MetaMethod.invoke(MetaMethod.java:111)
> at
> org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:636)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:345)
> at org.codehaus.groovy.runtime.Invoker.invokeMethod(Invoker.java:144)
> at
> org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:104)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethod(ScriptBytecodeAdapter.java:85)
> at FindSystemPrints.run(FindSystemPrints.gvy:15)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:521)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:462)
> at
> org.eclipse.eclipsemonkey.RunMonkeyScript.runGroovyScript(RunMonkeyScript.java:97)
> at org.eclipse.eclipsemonkey.RunMonkeyScript.run(RunMonkeyScript.java:60)
> at
> org.eclipse.eclipsemonkey.actions.RecreateMonkeyMenuAction$3.run(RecreateMonkeyMenuAction.java:158)
> at org.eclipse.jface.action.Action.runWithEvent(Action.java:499)
> at
> org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:539)
> at
> org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:488)
> at
> org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:400)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878)
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:143)
> at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95)
> at
> org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78)
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92)
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68)
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:376)
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:169)
> 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:589)
> at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336)
> at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
> at org.eclipse.core.launcher.Main.run(Main.java:977)
> at org.eclipse.core.launcher.Main.main(Main.java:952)
>
> Basically it could not find the class.  Of course I did not give up
> at this point, I tried using both the GroovyShell and
> GroovyClassLoader to compile the script and the same problem
> recurred.  Here is the kicker, if I write the groovy code to use
> reflection, the getMethod() call will also fail.  If I iterate
> through the array of methods after calling getMethods() and then
> invoke the object with that method object, it works....
>
> I am inclosing my little example script, the top part that is
> commented out, will work, while the invocation of
> resources.filesMatching() fails.
>
> I was hoping someone could point me in the right direction as to the
> cause of this problem.  I know that the Eclipse (OSGi) classloader
> model does violate the java classloader model, so I was thinking that
> I might try an adapter classloader for the GroovyClassLoader, to have
> it goto the bundle to get the class definition or I was wondering if
> there might be a way to more properly wrap java objects for groovy (
> I know it shouldn't be the case )?  I did go through the stack trace
> and it seems that there is a MetaClass and MetaMethod that get
> invoked that use a reflector before the actual object is actually
> invoked.  Is there a way to short circuit that or something?
>
>  Thanks for your help,
>  James E. Ervin, IV
>


FindSystemPrints.gvy (800 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Groovy Monkey ( Eclipse )

Jochen Theodorou
In reply to this post by James Ervin-2
[hidden email] schrieb:

> Hello,
>  I recently (today) was trying to hack the Eclipse Monkey plugin to
> support Groovy.  It looked rather straightforward as the Eclipse Monkey
> plugin is not particulary complicated, it is just that it only supports
> Java Script (yuck).
>
> I changed it to recognize groovy extensions inside the monkey
> subdirectories, that worked fine.  I then changed the RunMonkeyScript (
> take a look at the source code for the Eclipse Monkey at
> http://www.eclipse.org/dash ) to compile the groovy source, extract the
> dom information at the top of the script, put in the variable bindings
> and even got a requisite "Hello World" script to function.  This is
> where the ease and fun ends however.
>
> I wanted to port one of the example scripts called Find_System_Prints to
> groovy.  It was rather straightforward, but when it came time to
> reference one of the bound variables, in this case "resources", I got
> the following error:
>
> java.lang.NoClassDefFoundError: org/eclipse/dash/dom/resources/Resources

well... what classloader do you use as parent for the script?

[...]

> I was hoping someone could point me in the right direction as to the
> cause of this problem.  I know that the Eclipse (OSGi) classloader model
> does violate the java classloader model, so I was thinking that I might
> try an adapter classloader for the GroovyClassLoader, to have it goto
> the bundle to get the class definition or I was wondering if there might
> be a way to more properly wrap java objects for groovy ( I know it
> shouldn't be the case )?  I did go through the stack trace and it seems
> that there is a MetaClass and MetaMethod that get invoked that use a
> reflector before the actual object is actually invoked.  Is there a way
> to short circuit that or something?

just correct the classloader's and all will be fine. The parent of the
GroovyClassLoader must know where to find
org.eclipse.dash.dom.resources.Resources, if not all gets messed up.
Using the curreent thread's context class loader is no good solution,
you should give an explicit parent and ensure it does knwo the eclipse
classes. After this stage groovy will work fine.

Bye blackdrag
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Groovy Monkey ( Eclipse )

James Ervin-2
Thanks for the prompt reply, I have tried to fix the classloaders via
an adapter that caches the object classes for the binding and will fall
back to getting the class definition from the bundle.  This classloader
adapter is handed to GroovyClassLoader(), but I never see  
org.eclipse.dash.dom.resources.Resources attempt to be loaded.  Rather
I get the described exception that the apparently generated
GroovyReflector cannot find the class definition.  I am beginning to
think that I am screwing up the process of Binding the variables for
the script.  Where should I start looking?

James E. Ervin

Quoting Jochen Theodorou <[hidden email]>:

> [hidden email] schrieb:
>> Hello,
>>  I recently (today) was trying to hack the Eclipse Monkey plugin to
>> support Groovy.  It looked rather straightforward as the Eclipse
>> Monkey plugin is not particulary complicated, it is just that it
>> only supports Java Script (yuck).
>>
>> I changed it to recognize groovy extensions inside the monkey
>> subdirectories, that worked fine.  I then changed the
>> RunMonkeyScript ( take a look at the source code for the Eclipse
>> Monkey at http://www.eclipse.org/dash ) to compile the groovy
>> source, extract the dom information at the top of the script, put in
>> the variable bindings and even got a requisite "Hello World" script
>> to function.  This is where the ease and fun ends however.
>>
>> I wanted to port one of the example scripts called
>> Find_System_Prints to groovy.  It was rather straightforward, but
>> when it came time to reference one of the bound variables, in this
>> case "resources", I got the following error:
>>
>> java.lang.NoClassDefFoundError: org/eclipse/dash/dom/resources/Resources
>
> well... what classloader do you use as parent for the script?
>
> [...]
>> I was hoping someone could point me in the right direction as to the
>> cause of this problem.  I know that the Eclipse (OSGi) classloader
>> model does violate the java classloader model, so I was thinking
>> that I might try an adapter classloader for the GroovyClassLoader,
>> to have it goto the bundle to get the class definition or I was
>> wondering if there might be a way to more properly wrap java objects
>> for groovy ( I know it shouldn't be the case )?  I did go through
>> the stack trace and it seems that there is a MetaClass and
>> MetaMethod that get invoked that use a reflector before the actual
>> object is actually invoked.  Is there a way to short circuit that or
>> something?
>
> just correct the classloader's and all will be fine. The parent of
> the GroovyClassLoader must know where to find
> org.eclipse.dash.dom.resources.Resources, if not all gets messed up.
> Using the curreent thread's context class loader is no good solution,
> you should give an explicit parent and ensure it does knwo the
> eclipse classes. After this stage groovy will work fine.
>
> Bye blackdrag
>


12
Loading...