IntelliJ 9...

[wil.pannell]

...was just released today. I've been struggling this afternoon to
get the easyb intelliJ plugin to work with it, so far without any
luck.

Has anyone had any success using the plugin in IntelliJ 9, and if so,
would you post the steps necessary to configure it?

I do not think the steps outlined on the website are satisfactory to
configure the plugin in IntelliJ 9.

[Jeffrey Erikson]

I've recently updated to IntelliJ 9 myself, but haven't run the easyb
plugin yet. If I get a few free minutes this weekend, I'll play
around with it and see if I can come up with anything.

je

[wil.pannell]

Thanks for your reply. I look forward to what you find.

[Jeffrey Erikson]

So it looks like some pieces of the IntelliJ plugin API that had been
deprecated for a while may have finally gone away. I've done a little
bit of digging and opened an issue report here:
http://code.google.com/p/easyb/issues/detail?id=168

Wil, if you can provide any other information, it might be helpful in
fixing the problem.

je

[Jeffrey Erikson]

Version 0.9.6-1 of the easyb IntelliJ plugin is now available. You
should be able to install it directly from the Settings->Plugins menu
in IntelliJ. I've tested it under IntelliJ 8.0 and 9.0.

If you run into any issues with the plugin, please let us know.

je

On Dec 14, 10:35 pm, Jeffrey Erikson <jeffrey.erik...@gmail.com>

[demotivator]

I've tried it in both 8.1 and 9, and I'm wondering if I'm missing
something. It works if I manually setup a run configuration for each
story (painful), but I can't right click and run a story, it just
executes it as a groovy script and throws an exception. It also
doesn't recognize it at all in the code editor, it highlights
everything as unrecognized, like description, scenario, given, etc
even though they are valid easyb syntax.

Is there anything else I can try to configure? I checked the file
types, there's no easyb type. The groovy scripts and classes type
includes the appropriate story/specification items, though it seems
unnecessary if I'm using MyTestStory.groovy which gets matched
on .groovy anyway.

Are there any problems with running Groovy 1.7 with easyb?

Thanks,
--
Jason

On Dec 30 2009, 4:08 pm, Jeffrey Erikson <jeffrey.erik...@gmail.com>

[Andy]

Jason -- I can run easyb stories in IntelliJ 9 with Groovy 1.7.0 so
long as they end in .story -- it seems I'm having an issue trying to
run stories that end in .groovy though -- they keep getting executed
as if they have a main, etc.

[Jeffrey Erikson]

I'm seeing the same thing (doesn't run automatically when the story
ends in .groovy). I'll take a look and see if I messed something up
in 0.9.6-1.

je

> --
> You received this message because you are subscribed to the Google Groups "Easyb Users" group.
> To post to this group, send email to easyb...@googlegroups.com.
> To unsubscribe from this group, send email to easyb-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/easyb-users?hl=en.
>
>
>
>

[demotivator]

Thanks, renaming to .story helps somewhat in 9. Does the syntax
highlighting work for you? In the screenshot on the plugin page it
looks like it should be working better than it does for me, ie not
underlining all the easyb syntax.

I can right click run a story now. In 8.1 after making that change, it
blows up nicely:

Lorg/codehaus/groovy/reflection/ClassInfo;: Lorg/codehaus/groovy/
reflection/ClassInfo;
java.lang.NoClassDefFoundError: Lorg/codehaus/groovy/reflection/
ClassInfo;
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2291)
at java.lang.Class.getDeclaredField(Class.java:1880)
at java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:
1610)
at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52)
at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:425)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:413)
at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310)
at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:547)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:
1583)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:
1496)
at java.io.ObjectInputStream.readOrdinaryObject
(ObjectInputStream.java:1732)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:
1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:
1871)
at java.io.ObjectInputStream.readOrdinaryObject
(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at org.easyb.plugin.remoting.RemoteExecutionListener.run
(RemoteExecutionListener.java:32)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.ClassNotFoundException:
org.codehaus.groovy.reflection.ClassInfo
at com.intellij.ide.plugins.cl.PluginClassLoader.loadClass
(PluginClassLoader.java:54)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
... 21 more

java.lang.NullPointerException
at org.easyb.plugin.ui.EasybPresenter.appendOutput
(EasybPresenter.java:105)
at org.easyb.plugin.ui.EasybPresenter.textAvailable
(EasybPresenter.java:99)
at org.easyb.idea.runner.EasybProcessListener.onTextAvailable
(EasybProcessListener.java:29)
at sun.reflect.GeneratedMethodAccessor80.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.intellij.execution.process.ProcessHandler$5.invoke
(ProcessHandler.java:199)
at $Proxy66.onTextAvailable(Unknown Source)
at com.intellij.execution.process.ProcessHandler.notifyTextAvailable
(ProcessHandler.java:159)
at com.intellij.execution.process.OSProcessHandler$2.textAvailable
(OSProcessHandler.java:127)
at com.intellij.execution.process.OSProcessHandler
$ReadProcessThread.checkTextAvailable(OSProcessHandler.java:322)
at com.intellij.execution.process.OSProcessHandler
$ReadProcessThread.run(OSProcessHandler.java:280)
at com.intellij.openapi.application.impl.ApplicationImpl$5.run
(ApplicationImpl.java:8)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:
441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask
(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run
(ApplicationImpl.java:5)

and from the console:

java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:
92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at java.io.ObjectOutputStream$BlockDataOutputStream.drain
(ObjectOutputStream.java:1838)
at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode
(ObjectOutputStream.java:1747)
at java.io.ObjectOutputStream.writeNonProxyDesc
(ObjectOutputStream.java:1249)
at java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:
1203)
at java.io.ObjectOutputStream.writeOrdinaryObject
(ObjectOutputStream.java:1387)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:
1150)
at java.io.ObjectOutputStream.writeFatalException
(ObjectOutputStream.java:1538)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:
329)
at org.easyb.plugin.remoting.RemoteUtils.safeWriteObject
(RemoteUtils.java:31)
at org.easyb.plugin.remoting.ExecutionListenerProxy.startStep
(ExecutionListenerProxy.java:31)
at org.easyb.listener.BroadcastListener.startStep
(BroadcastListener.java:31)
at org.easyb.domain.Story.execute(Story.java:27)
at org.easyb.BehaviorRunner.executeBehaviors(BehaviorRunner.java:117)
at org.easyb.BehaviorRunner.runBehaviors(BehaviorRunner.java:82)
at org.easyb.plugin.remoting.RemoteRunner.main(RemoteRunner.java:26)
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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:
90)

Unfortunately I have an issue with IntelliJ 9 preventing me from using
it for this project, so I'm kinda stuck right now.
--
Jason

[Jeffrey Erikson]

Can someone confirm that running stories that ended in .groovy ever
worked in the plugin? I've installed a number of older versions of
the IntelliJ plugin and run them under IntelliJ 8.1.4 (since they
won't work under 9.0), and each time, they automatically get run as a
Groovy script. I can set up a Run Configuration to execute them using
easyb, but only stories that end in .story (or specifications that end
in .specification) get the option to run using easyb by
right-clicking.

Looking more closely at the API for associating plugins with files, it
looks like it would be difficult to associated *Story.groovy files
automatically. It looks like the registerFileType() method used to do
the association actually looks at *extensions*. The best we might be
able to do is actually add the .groovy extension to the list, but then
*every* .groovy file would end up with the option to be run under
easyb.

I'm not sure what the best solution is at this point, other than
documenting that *Story.groovy files need to be run with a manually
configured Run Configuration.

Thoughts?

je

[Jeffrey Erikson]

OK, I discovered what the problem is: basically, for versions of
IntelliJ prior to 9.0, we'll need to bundle the groovy-all-xxx-.jar
with the plugin libs. Rod Coffin and I were actually chatting about
whether or not that particular jar file needed to be included any
more, and we decided to leave it out at this point since things seemed
to work on my system here and it wasn't automatically included in the
plugin upload package (and significantly increases its size).

I'll modify the build to automatically include the Groovy dependency
and upload a new version of the plugin shortly.

je

[Jeffrey Erikson]

Just in case I wasn't clear about which problem I was addressing:
embedding the groovy jar solves the broken pipe issue in IntelliJ 8.1.

je

[Jeffrey Erikson]

Version 0.9.6-2 of the easyb IntelliJ plugin is now available to
install via the IntelliJ plugins site. You should be able to
install/upgrade directly from within IntelliJ.

Version 0.9.6-2 fixes a 'broken pipe' problem that occurs in IntelliJ
IDEA versions prior to 9.0 using version 0.9.6-1 of the easyb plugin.

Please let us know if you run into any other problems with the plugin.

Thanks.

je

On Thu, Jan 7, 2010 at 6:41 PM, Jeffrey Erikson

[Jeffrey Erikson]

On Thu, Jan 7, 2010 at 5:51 PM, demotivator <jason.m...@gmail.com> wrote:

> Does the syntax highlighting work for you? In the screenshot on the plugin page it
> looks like it should be working better than it does for me, ie not underlining all the easyb syntax.

I've gone back a few versions of the plugin, and it looks like the
underlining is dependent on the IntelliJ version. It looks like the
screenshot was taken back in IntelliJ version 7, and I'm guessing they
decided that it would now be helpful to point out syntax that may or
may not be valid. If you put the following code into IntelliJ, you'll
see that the "real" property is highlighted; however, even though
"fakeProperty" is valid at runtime, since it's a "dynamic" property,
IntelliJ doesn't really recognize it during editing so will underline
it.

class Faker {

def realProperty = "this is a real property"

def junk = [:]
def propertyMissing( prop, val ) { junk[ prop ] = val }
def propertyMissing( prop ) { junk[ prop ] }

static void main( args ) {
def f = new Faker()
println f.realProperty

f.fakeProperty = "This is a fake property"
println f.fakeProperty
}
}

In the IntelliJ plugin code, it looks like since we're associated with
Groovy files, we're getting the Groovy syntax highlighting. Since the
Groovy highlighting doesn't recognize easyb keywords, I'm guessing
that's why we now have the underlining. I'm relatively new at
IntelliJ plugins, so it might take me a little while, but I'll dig in
and see if we can get syntax highlighting working a bit more directly
for easyb syntax.

BTW, thanks for your input! Let us know if we can make any other
improvements or if you run into any other problems.

je

[demotivator]

Thanks so much! The updated plugin is working fine now in 8.1.4. The
underlining isn't a big deal at this point since it runs fine. I've
gotten used to a bit of that in my groovy code anyway. Now I guess its
time to finally get my tests written up!

--
Jason

On Jan 7, 7:09 pm, Jeffrey Erikson <jeffrey.erik...@gmail.com> wrote: