I’m writing this post today out of depression. Sometimes you find yourself in a place where you just wanna give up. Sometimes life can throw you a curve ball and you just can’t nail it like you want to. I find myself in this position all too frequently. Well part of my depression stems from my partially successful attempt at creating an XSLT test app with groovy. While I love the Groovy technology, I have to concede to being an ametuer. In other words I’m not proficient enough with it yet where I can spread my wings and run all the way with it. My app reflects these facts. Also, I’m having trouble integrating it into my development style. You see the Groovy plugin for Eclipse is still immature and I can’t use the one for Idea since we don’t have license for Idea5.x here. (We still run Idea 4.5.4.) Getting into a Groovy development groove is going to take time and practice. The major challenges I face are those with the test, fail, code, test, pass, refactor, test, pass, deploy cycle that XP encourages. (Of course there are several more iterations of test-fail-code in the cycle but as I have limited space you’ll have to cut me some slack.) On top of that I have this problem with being a general idiot that’s getting in the way of my personal growth. Have you ever done something so stoopid to someone that you care about and had no way to take it back? If life only had one of those undo buttons buttons from the MS Word toolbar. (You know the one with the little curved arrow that clears all of your stoopid mistakes and puts you back in a safe editing mode when you accidentally drag some selected text to a weird location in your document?) Well anyhow, I said I wasn’t going to slip up and reveal anything personal since that content is supposed to be irrelevant to the purpose of this blog. Back to programming related discussion…
While using Groovy I found that I have to make little workarounds to get things happening. For example, in Idea I set an external tool to run the current file with the Groovy interpreter. That works fine until my file references another groovy source defined class that has not yet been compiled. I set a classpath pointing to the source file’s package root. For example, I’ll have
/home/me/myproj/src/main/groovy/com/my/package/MyGroovy.groovy and the command will be something like:
groovy -cp /idea/complicated:/class/path:/with/many/entries:/that/confuse/you:/home/me/myproj/src/main/groovy /home/me/myproj/src/main/groovy/com/my/package/MyGroovy.groovy
As soon as MyGroovy.groovy references MyOtherGroovy.groovy in the same folder and package I run into “Cannot resolve symbol” errors. So then I’m forced to break into Maven and compile everything. This works ok except for the fact that the resulting Jar I build with Maven has a dependency on the groovy API which is not in the same folder. (I’m thinking the assembly plugin will clear that up but I have not been able to download it with all the trouble going on with the codehaus server.) So Now I have a smbolic link in the build “target” folder pointing to the groovy API just so I can run the jar. Well that works fine except for now my unit tests start acting weired because I find out they now have duplicate class definitions. You see I run my unit tests as uncompiled source and the scompile puts these the binaries into the Idea classpath which just serves to confuse things. I’ve just not been having any luck lately. Talk to me people!