Lately I’ve been trying my hand at non Java languages on the JVM. Since Groovy is quite popular and a well supported language, I was giving it a go. Maven and Netbeans are my preferred project and IDE systems, and I had used GMaven at work so I knew it COULD be done. As a good TDD Developer I decided my first task would be to write a failing unit test and thus began my troubles.
GMaven works by generating Java stubs which are then compiled. This way the IDE has excellent intellisense, static analysis, and other goodies when you use the Groovy code in Java. This has the side effect of requiring a clean and build for every change. The extra step ends up really slowing down my rhythm and I tried to avoid it. Browsing around, it seemed like the groovy-eclipse-compiler plugin would help here. After setting that up, however, my trivial unit test always passed when it should have failed. Eventually I gave up and went back to GMaven.
The GMaven plugin has a project archetype. (mvn archetype:generate -DarchetypeGroupId=org.codehaus.gmaven.archetypes -DarchetypeArtifactId=gmaven-archetype-basic for the lazy), but the default implementation has busted unit tests. I had to remove the import statements from the examples before I could run them. Finally I was given my red bar and could begin coding in earnest.
Overall, this has been far more work than I had hoped. It seems like the GMaven project is thinking about merging with the eclipse compiler project. They hope to solve the stub issue this way, but that seems to be a ways off.