This week, I tried to get my Groovy+Eclipse setup back and running, because I needed to debug a complex script that was outputting 15-20 line stack traces with a lot of useless information about Groovy internals. Finding the exact error message was taking me several seconds and no matter how hard I was trying to fix things, I was getting other and other errors. A step by step debugger was more than welcome.
I looked once more at Groovy web site for the presence of the plugin for Eclipse 4.4. Up to last Monday, release was supposedly imminent. Searching on Google was giving information that the special STS bundle of Eclipse 4.4 was providing Groovy integration. Wow, will I really have to install a special version of Eclipse to get Groovy now? I didn’t want to get STS which will give me Grails, Spring, etc, which I don’t need.
But last Monday, release was there. I tried to install it, but I found out it couldn’t install because of a compatibility problem with some of the features I had in my environment. It is possible that the plugin works only with the original version of 4.4, not the SR1. I tried a couple of times without success, then fell back on the development build. This one installed. I’m not sure it will be stable, but it was better than nothing. However, the same way as in August 2014, I was consistently getting the following error message:
Conflicting module versions. Module [groovy-all is loaded in version 2.2.1 and you are trying to load version 2.3.6
No matter how hard I searched for a solution, there was NO result. I opened my Maven POM file in Eclipse, pulled the dependency hierarchy, searched for Groovy, and found only one Groovy-All dependency. Nothing other than Groovy 2.3.6 was pulled by transitivity from other dependencies. Any search on Google was yielding results about Grails. Some people fixed the issue by removing the GROOVY_SUPPORT container from the build path: well, no GROOVY_SUPPORT in my build path.
I then thought about running a simple Java program in the same project as my Groovy script and output the class-path from the System.getProperties() object. Looking at the JARs in the class-path, I found no Groovy dependency. From my dummy program, I then tried to call my Groovy script. The script is compiled just as a regular class with a main method that I called… with success!
I then found out that you can execute a Groovy script as a regular Java Application in Eclipse: no need to run as a Groovy script. The script runner most likely involves a wrapper with a Groovy 2.2.1 dependency. This wrapper is built into Eclipse’s Groovy plugin. Running directly as a Groovy class avoided the introduction of the Groovy 2.2.1 dependency in the class-path alongside Groovy 2.3.7 so I got passed the hurdle and was able to more easily debug my code! During the process, I updated to Groovy 2.3.7 to match what was used by Groovy Eclipse.
The newest version of the Groovy plugin behaved a bit better, allowing me to use conditional breakpoints a couple of times, as opposed to the last version for which that was consistently failing with compilation errors.
For the complex stack traces, there is a simple solution: the StackTraceUtils class has methods to sanitize stack traces, removing frames related to Groovy internals. I just wrote a small uncaught exception handler and registered that as the default handler, and tada, more compact exception traces! Of course, I have to do it for each of my scripts, but that’s just a one-liner since I put the code registering the default handler in a utility method.