Run As Groovy Console/Shell does not bootstrap its dependencies

[mauromol]

When you create a project using Groovy 2.5, Run As -> Groovy Console does not work any more because groovy.jar does not contain the necessary classes. groovy-console should be added to the project build path or, even better, at least in the launch configuration that gets created when you do Run As -> Groovy Console.

I suspect something similar applies to Run As -> Groovy Shell, but I never used it.

[eric-milles]

https://github.com/groovy/groovy-eclipse/wiki/3.0.0-Release-Notes#support-for-ant-groovy-shell-and-groovy-console

[mauromol]

I know that I can workaround this by adding the JARs by myself (said that it's not that easy if your project isn't using neither Maven nor Gradle), but I don't think Greclipse should be "broken by default"... ;-)
Couldn't those JARs be automatically added by Greclipse to the "Classpath" tab of the launch configuration when created with Run As -> Groovy Console/Shell?

[eric-milles]

If not using Ivy, Maven, Gradle or similar, you can add the jars to your ~/.groovy/lib directory.

To carry the jars, the release must grow in size. To provision them on-demand, it must go to the internet. I'm not sure what kind of acceptance there is for either of those options. I wasn't really sure what to do once groovy-all was broken up, so I left it to the user to choose how to get the jars if they want to use Console or Shell.

[mauromol]

I don't think that groovy + groovy-console + groovy-shell is that bigger than the old groovy-all... is it? If it is not, I don't think there's a significant release grow, at least not for this reason, between the Groovy 2.4 compiler artifact and the 2.5 one...

Downloading on-demand is something that other plugins actually do (I can think of the SVN connectors downloaded on demand when necessary), but I think it's a lot more work to make UIs, think of the right workflow, etc..

At least I think that Run As -> Groovy Console/Shell should be removed if it can't work, or some message should show up to say what to do to make it work. However I think this is quite a hit on user experience if the user has to retrieve and add JARs manually.

I personally use Groovy Console regularly to test code.

[eric-milles]

It is hard to determine ahead if all the dependencies are present in a project already. Allowing them to run and display ClassNotFound exceptions let's you know explicitly what is missed. These exceptions could possibly be parsed from the process output and some kind of message could be displayed listing the common source of the missing class.

Here is the launch configuration class that sets it all up for Groovy Console: https://github.com/groovy/groovy-eclipse/blob/master/ide/org.codehaus.groovy.eclipse.ui/src/org/codehaus/groovy/eclipse/launchers/GroovyConsoleLaunchShortcut.java

[eric-milles]

It may be possible to write a groovy script that uses @Grab annotations to indicate the dependencies and launches the Console or Shell. I think this could be experimented with and launched as a Groovy Script just to see if the idea works before embedding it in the eclipse tooling.

[eric-milles]

There are also the system properties "groovy.starter.conf" and "groovy.starter.conf.override" which can be used to provide loader configuration. Looks like it supports grab as well.

[eric-milles]

I had a new idea for this. There are actually 2 classpaths for console/script/shell launches. The first is the new VM's classpath, which must contain Java plus enough Groovy to drive the console, script or shell. The second is the classpath that the console, etc. exposes to you to mimic the project's classpath.

It is this first classpath that is being set improperly. It is set to the project's classpath when it should really be referring to the internally bundled groovy jar and enough additional jars to bootstrap the console/script/shell. There should be no conflict with the project's dependencies if this first classpath is altered to contain different groovy jars from the project.

[eric-milles]

I figured enough to get the classpath bootstrapped from embedded jars:

However, I'm running into problems with how GroovyMain and Console handle the project's classpath. Groovysh is well positioned, but the other two need some help.

[eric-milles]

Quick update: I have all the changes in place for this. I'm just waiting on Groovy 2.5.9 which contains the necessary class loader support. If I submit my changes before that, I will break script or shell support for Groovy 2.5 -- and I don't want to break functionality.

[mauromol]

Great news!

[eric-milles]

If you need to, you can use branch issue890 to build the plugins/features and try this out.