OpenAPI and JSR-241 (Groovy) Follow

Would anyone at JetBrains care to answer?

TIA

I'm sure some of us would really appreciate it if someone at JetBrains
could confirm once and for all whether Aurora's or Pallada's OpenAPI
could allow such a sophisticated integration as the one described in
the above thread.

Myself and other groovy dev folks are currently working on an
integration for Pallada, trying out all the new compiler api stuff..

M

Mark Lussier wrote:

Myself and other groovy dev folks are currently working on an
integration for Pallada, trying out all the new compiler api stuff..

Now that sounds nice.... look forward to trying it out when you have
something.

Mark

Sounds pretty interesting, though I've got to admit I'd be more
interested in similar support for Jython. I've scanned the groovy web
pages, but so far haven't really seen a compelling reason to switch over
from jython to groovy. That said, I'm happy to be educated here :)

Guy


Mark Derricutt wrote:

Mark Lussier wrote:

>> Myself and other groovy dev folks are currently working on an
>> integration for Pallada, trying out all the new compiler api stuff..

Now that sounds nice.... look forward to trying it out when you have
something.

Mark

Guy Gascoigne-Piggford wrote:

Sounds pretty interesting, though I've got to admit I'd be more
interested in similar support for Jython. I've scanned the groovy web
pages, but so far haven't really seen a compelling reason to switch over
from jython to groovy. That said, I'm happy to be educated here :)

Both would be excellent. Although what we'd really need to see evole is
a Refactoring OpenAPI. When you say have JavaRefactoringComponent
implements RefactoringThing that has methods for "extractMethod". That
way consistent refactorings can be implemented for different languages.

Myself and other groovy dev folks are currently working on an
integration for Pallada, trying out all the new compiler api stuff..

Let's ceize this opportunity to ask what would we, IntelliJ and Groovy
users, expect from such a plugin ?
Let's brainstorm and find some interesting features that are required, such
as:
- syntax highlighting
- compiling / debugging / running
- a scratchpad to play with groovy inside an interactive shell
- JUnit tests integration (tests written in groovy)
- refactoring (if that's possible to hook in IntelliJ's refactoring API)

What else do we need ?

--
Guillaume Laforge
http://glaforge.free.fr/weblog

Guillaume Laforge wrote:

- syntax highlighting
- compiling / debugging / running
- a scratchpad to play with groovy inside an interactive shell
- JUnit tests integration (tests written in groovy)
- refactoring (if that's possible to hook in IntelliJ's refactoring API)

- support find class
- support find symbol
- support intellisense

- groovy specific intentions and inspections
- groovy refactorings ( convert to closure maybe )

Mark

I'm actually looking to write a plugin for WebWork that would allow for, among other things, code completion of the expression language. I am betting that the Ognl/Jython/Groovy crew could all team up here to work on some building blocks to allow for some of these features in various plugins.

Hi Mark,

That's good news indeed! I have started looking into the IDEA integration but could not see any CVS updates since late January. So far, I've only made minor changes to get the plugin to work with IDEA 4.0.2 (build 1179).

It would be great if you or one of the groovy-dev folks could check this work in on another branch perhaps.

Thanks,

Franck

- support find class
- support find symbol
- support intellisense

- groovy specific intentions and inspections
- groovy refactorings ( convert to closure maybe )

Thanks Mark, this is exactly the level of integration that I had in mind.

Do you guys know if this can be done with the Open API in IDEA 4.x?

Franck Rasolo wrote:

Thanks Mark, this is exactly the level of integration that I had in mind.
Do you guys know if this can be done with the Open API in IDEA 4.x?

The intentions and inspections certainly can, not sure about the rest
thou...

--
Discouragement is a dissatisfaction with the past, a distaste for the
present, and a distrust of the future - Maree De Jong, CLCA.

Mark Derricutt --- mark@ talios.com --- http://www.talios.com

The idea of having another branch would be to isolate Pallada-specific features from Aurora-compatible ones.

- a scratchpad to play with groovy inside an interactive shell

this can be done using BSFConsole(http://www.intellij.org/twiki/bin/view/Main/BsfConsole) as soon as Groovy team will fix a bug in GroovyClassLoader (http://jira.codehaus.org/secure/ViewIssue.jspa?key=GROOVY-452)

Hi Konstantin,

"Konstantin Sobolev" <k_o_s@mail.ru> a écrit dans le message de
news:1630422.1084024430120.JavaMail.itn@is.intellij.net...

- a scratchpad to play with groovy inside an interactive shell

>

this can be done using

BSFConsole(http://www.intellij.org/twiki/bin/view/Main/BsfConsole) as soon
as Groovy team will fix a bug
>in GroovyClassLoader
(http://jira.codehaus.org/secure/ViewIssue.jspa?key=GROOVY-452)

In fact, in CVS Head, we commented those offending lines, because we noticed
that some jars delimit the entries in very different ways, so it's not that
easy to parse the Class-Path attribute. For the current code in Head, look
at:
http://cvs.groovy.codehaus.org/groovy/groovy-core/src/main/groovy/lang/GroovyClassLoader.java?rev=1.20&view=auto

Did you try with the latest groovy snapshot jar ? Since I've fixed the
deployment of the snapshot on the distribution site, you can pick it at:
http://dist.codehaus.org/groovy/dist/groovy/jars/

--
Guillaume Laforge
http://glaforge.free.fr/weblog

Thanks Guillaume, 1.0-rc1 snapshot resolves this issue. But I still can't make it work with BSFConsole. First Groovy can't find it's jars (groovy-<![CDATA[.jar, asm-]]>.jar) that are in plugins/BSFConsole/lib, although IDEA's plugins classloader which is used by BSFManager does see them. I tried to:
- include them in java.class.path property
- passing the same path to bsfManager.setClassPath(...)
- setting groovy.home and classwordls.conf system properties
Unless I put them to idea/lib, Groovy throws ClassNotFound (groovy/lang/Script) on every attempt to evaluate something.

OK, I put them in idea/lib, now when I try to evaluate any expression I get ClassCastException:

groovy.lang.GroovyRuntimeException: Failed to create Script instance for class: class groovy_console. Reason: java.lang.ClassCastException
at org.codehaus.groovy.runtime.InvokerHelper.createScript(InvokerHelper.java:395)
at groovy.lang.GroovyShell.parse(GroovyShell.java:362)
at groovy.lang.GroovyShell.parse(GroovyShell.java:344)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:327)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:282)
at org.codehaus.groovy.bsf.GroovyEngine.eval(GroovyEngine.java:146)
at org.kos.bsfconsoleplugin.BSFInterpreter.eval(BSFInterpreter.java:153)
at org.kos.bsfconsoleplugin.BSFInterpreter$1.run(BSFInterpreter.java:118)
at java.lang.Thread.run(Thread.java:534)
Caused by: java.lang.ClassCastException
at org.codehaus.groovy.runtime.InvokerHelper.createScript(InvokerHelper.java:375)
... 8 more

I couldn't find groovy_console class anywhere, I suppose it gets constructed dynamically. What am I doing wrong?

I remember that somehow I made groovy-1.0-beta2 to work with BSF..

"Konstantin Sobolev" <k_o_s@mail.ru> a écrit dans le message de
news:31266962.1084106911861.JavaMail.itn@is.intellij.net...

Thanks Guillaume, 1.0-rc1 snapshot resolves this issue. But I still can't

make it work with BSFConsole. First Groovy can't find it's jars
(groovy-<![CDATA[.jar, asm-]]>.jar) that are in plugins/BSFConsole/lib,
although IDEA's plugins classloader which is used by BSFManager does see
them. I tried to:

- include them in java.class.path property
- passing the same path to bsfManager.setClassPath(...)
- setting groovy.home and classwordls.conf system properties
Unless I put them to idea/lib, Groovy throws ClassNotFound

(groovy/lang/Script) on every attempt to evaluate something.

In fact, in the last snapshot, the class path was not expanded correctly.
I've fixed that today. Now we can even parse a badly formated class-path in
the manifest.
I've just rebuilt a new snapshot of Groovy. You can pick it up at the usual
place:

>

OK, I put them in idea/lib, now when I try to evaluate any expression I

get ClassCastException:
>

groovy.lang.GroovyRuntimeException: Failed to create Script instance for

class: class groovy_console. Reason: java.lang.ClassCastException

at

org.codehaus.groovy.runtime.InvokerHelper.createScript(InvokerHelper.java:39
5)

at groovy.lang.GroovyShell.parse(GroovyShell.java:362)
at groovy.lang.GroovyShell.parse(GroovyShell.java:344)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:327)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:282)
at org.codehaus.groovy.bsf.GroovyEngine.eval(GroovyEngine.java:146)
at org.kos.bsfconsoleplugin.BSFInterpreter.eval(BSFInterpreter.java:153)
at org.kos.bsfconsoleplugin.BSFInterpreter$1.run(BSFInterpreter.java:118)
at java.lang.Thread.run(Thread.java:534)
Caused by: java.lang.ClassCastException
at

org.codehaus.groovy.runtime.InvokerHelper.createScript(InvokerHelper.java:37
5)

... 8 more

>

I couldn't find groovy_console class anywhere, I suppose it gets

constructed dynamically. What am I doing wrong?
>

I remember that somehow I made groovy-1.0-beta2 to work with BSF..

Ooops, sorry, I'm reposting... I hit the wrong key, sorry for the half
finished post :-/

"Konstantin Sobolev" <k_o_s@mail.ru> a écrit dans le message de
news:31266962.1084106911861.JavaMail.itn@is.intellij.net...

Thanks Guillaume, 1.0-rc1 snapshot resolves this issue. But I still can't

make it work with BSFConsole. First Groovy can't find it's jars
(groovy-<![CDATA[.jar, asm-]]>.jar) that are in plugins/BSFConsole/lib,
although IDEA's plugins classloader which is used by BSFManager does see
them. I tried to:

- include them in java.class.path property
- passing the same path to bsfManager.setClassPath(...)
- setting groovy.home and classwordls.conf system properties
Unless I put them to idea/lib, Groovy throws ClassNotFound

(groovy/lang/Script) on every attempt to evaluate something.

In fact, in the last snapshot, the class path was not expanded correctly.
I've fixed that today. Now we can even parse a badly formated class-path in
the manifest.
I've just rebuilt a new snapshot of Groovy. You can pick it up at the usual
place:
http://dist.codehaus.org/groovy/dist/groovy/jars/
Could you please try with this snapshot, please ?

OK, I put them in idea/lib, now when I try to evaluate any expression I

get ClassCastException:
>

groovy.lang.GroovyRuntimeException: Failed to create Script instance for

class: class groovy_console. Reason: java.lang.ClassCastException

at

org.codehaus.groovy.runtime.InvokerHelper.createScript(InvokerHelper.java:39
5)

at groovy.lang.GroovyShell.parse(GroovyShell.java:362)
at groovy.lang.GroovyShell.parse(GroovyShell.java:344)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:327)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:282)
at org.codehaus.groovy.bsf.GroovyEngine.eval(GroovyEngine.java:146)
at org.kos.bsfconsoleplugin.BSFInterpreter.eval(BSFInterpreter.java:153)
at org.kos.bsfconsoleplugin.BSFInterpreter$1.run(BSFInterpreter.java:118)
at java.lang.Thread.run(Thread.java:534)
Caused by: java.lang.ClassCastException
at

org.codehaus.groovy.runtime.InvokerHelper.createScript(InvokerHelper.java:37
5)

... 8 more

>

I couldn't find groovy_console class anywhere, I suppose it gets

constructed dynamically. What am I doing wrong?

The Groovy Console uses a groovy script called Console.groovy in the package
groovy.ui
The compiled class is in the jar. But I don't think this error is related to
that console.
The line throwing the exception is the one within which we specify the
binding used by the script
(ie. the context parameters you pass to the script :
setBinding(someBinding) )
So perhaps there's a bug in the BSF integration... let's investigate that.

I remember that somehow I made groovy-1.0-beta2 to work with BSF..

I know some people used Groovy through BSF, so it must be working in a way
or another I guess.

--
Guillaume Laforge
http://glaforge.free.fr/weblog

I finally managed to solve it. See http://jira.codehaus.org/browse/GROOVY-475

With this patch everything works like a charm.