Sword Systems

I love it when other people do my work for me.  For example, I needed to store a few random settings in a Grails app, such as the last time a service polled an external resource.  So I went to the main Grails Plugin site and, sure enough, someone else has already written a Grails Settings plugin.  It needs a few enhancements to do what I want, but it’s better than starting from scratch.  While I was perusing the plugin list, I found a few others that can replace features I had started to sketch out (like Taggable) and was inspired by yet others that would let me easily add features that I hadn’t thought of before (like Commentable and Sparkline).

Another example is yet another good post by my friend and coworker Jeff Erikson detailing his research into problems with Grails config options getting wiped during integration tests.  I had been meaning to write up a note about how the GrailsUnitTestCase class hides the true config settings, so you don’t want to accidentally use it in integration tests.  Jeff took my little tip a lot farther with his post.  Thanks, Jeff!

grails, groovy, unit test

The groovy support in Eclipse leaves a bit to be desired. “Tell me something new” you say. How about – The groovy support in maven projects within eclipse leaves a lot to be desired, but it does at least exist, so long as you are willing to work at it a bit.

Rather than posting the details off in the wilderness of my own blog, I responded to a post on the m2eclipse (the maven-eclipse plugin) mail list from last Fall where someone was asking how to add groovy support to maven projects. The author of the m2eclipse plugin stated that the groovy plugin needed to support some hooks into m2eclipse. While that may be true to get fully automated setup and synchronization, you can get the two plugins working together. See this thread for the info:
http://www.nabble.com/Using-M2Eclipse-together-with-Groovy-td19261256.html

eclipse, groovy, m2eclipse, maven

I have been using the Groovy plugin for Eclipse for about 18 months now. First let me say thanks to the team who has put it together. I can’t really complain about any problems since it is a volunteer effort and I haven’t volunteered. And over the time I have used the plugin it has gotten some pretty nice improvements, especially for code refactoring and auto-completion. It’s debugging capability has always been good (with a few quirks). The fact that I can debug scripts as well as regular classes kept me from switching to NetBeans when the major upgrade of that product came out in November without that feature (hmmm… I see there are some upgrades for NB. Yet another thing to add to my to-do list to check out). Overall I find the plugin perfectly capable when writing scripts, especially in small projects. For writing classes however, especially in a large project or when mixed with Java classes, it’s a PITA.

For those that cannot or do not want to move from Eclipse to IDEA or NetBeans, here are a few tips for getting by with the plugin for now:

1) The largest issue is a memory leak. I posted to the groovy user list about it over a year ago. (My explanation of the problem in that post was slightly incorrect. The problem will occur in any project with a lot of classes on the class path, not just one that includes another project.) I think the issue has gotten better in some circumstances, but it still makes it impossible for me to easily integrate groovy classes into my major projects.
Work Around: I have a small “GroovySandbox” project that has the class directory and key required libraries from my main project on its classpath. (Do not include the main project as a dependent project because you will have the exact same memory problem.) I write new scripts and classes in this project and then when they are ready, I copy them into the main project. The memory issue still has an affect, but I can work a full day on groovy files without having to restart eclipse rather than having to restart every 20-30 minutes.

2) Whenever I modify the class path of a project that includes groovy classes (thus triggering a clean build by Eclipse), the groovy class files are wiped with everything else and are not regenerated. I have to go in and touch each groovy class to get it to compile.
Work Around: I now have enough groovy classes that this isn’t feasible, so I created an ant target that compiles only the groovy classes and I trigger it from within Eclipse when necessary. Eclipse detects the newly generated class files and the remaining java classes I have that are dependent on the groovy classes finish compiling. (Why do I have to mix groovy and java so much? See #1, above and #3, below. Unless I want to take advantage of groovy syntax features a lot, I stick with Java.)

3. When I open a groovy class in the editor, it often doesn’t populate the Outline view. Makes it hard to navigate the file.
Work Around: Touch the file, or add-and-delete a space. This was a pain when using CVS for our SCM since the files were tagged as modified, but since switching to Subversion there hasn’t been a problem. I guess Subversion uses something beyond file dates to track mods.

4. When debugging, if I try to step into a class (java or groovy) that is included from another project (which I do frequently since nearly all classes are in the main project due to #1, above), I get an error window saying that the class is part of the Groovy Libraries plugin path and that the path is not modifiable. The screen doesn’t give you a button to modify the source lookup path for the directory/jar. (This one is relatively new. It started happening in some update around the beginning of the year.)
Work Around: Go into the project properties->Java Build Path->Libraries and manually set the “Source Attachment” property for the offending directory/jar. The next time you start the debugger, it will let you step in without a problem.

eclipse, groovy, groovy plugin

I first saw Groovy in Nov 2007 and promptly decided to dive in over my head and write a DSL in it. One thing that I never quite got was why one would want to use a Category versus ExpandoMetaClass. Having to create a class with a bunch of static methods and then surround other classes in it didn’t seem very elegant. Directly adding behavior to a class with an ExpandoMetaClass is much more straightforward. I thought that the Category approach must be a hold over from Groovy releases prior to 1.5 when ExpandoMetaClass was added. The only use case I could come up with for them was if you wanted to add the same functionality to a set of classes – sort of an AOP view of things.

But then Groovy 1.6 came out and I saw that the team had added some very cool annotations to make categories even more powerful and easier to use. (See InfoQ for a great write up of the 1.6 features.) Okay – you don’t improve a dead feature, so what was I missing?

This past weekend I got a chance to ask the person from whom I first learned about Groovy, Scott Davis. His Blue Pill and Red Pill talks at NFJS were what first got my mind churning about the possibilities that Groovy opened up. Before sitting in on another of his talks at the most recent NFJS conference this past weekend, I asked him why one would use categories in a DSL rather than modifying meta classes? His answer told me that I was asking the wrong question. The strength of categories is in scoping – modifying behavior for a limited period of time. The primary example he gave was for unit tests. A category can short circuit certain behavior (like retrieving info from a DB or from a file) to make it easier to test certain behavior in isolation. This makes a lot of sense. Mocks/stubs have their place; they are useful when you need to work with an object in a very limited sense – just a few calls. Then there are times when you want a real object doing 95% of what it is supposed to do, but you want to take over in just a few situations to be able to insert custom behavior. e.g. in a unit test when you want to short circuit network or file-based activity or you want to purposefully force an error condition.

It so happens that I really need to improve the unit tests for some network-based components in the ETL system that I work with. The primary one is called GetHttpContent, so you can imagine that unit testing it can be a pain. I’ll give Categories a closer look to see if they can help me out. Unfortunately, I have to wait until we finish shifting to a our new project structure because right now there are so many dependencies in the primary project that if I work on a groovy file in that project in Eclipse I lose ~20M of memory every time I edit it. But the limitations (and benefits) of the Eclipse groovy plugin can wait for another post.

ExpandoMetaClass, category, groovy, unit test