Testing J2EE components has always been a difficult task, which is probably why I see so many web projects that have few tests written for the web layer or sometimes none at all. Late last year Spring announced the release of Spring 2.5 , with some nice additions to the suite of mock testing objects for unit testing web components. That’s right unit testing web components, not in container testing. So like any good agile programmer let’s start with the test first.

I’m a huge fan of Grails, and after hearing a couple of talks on it at CodeMash last week I decided to check in on it’s progress. I had first caught wind of Grails last winter when I purchased the book The Definitive Guide to Grails. I had been attempting to learn Ruby on Rails, and was quite unimpressed. I’m a big fan of the whole “Convention over configuration” way of thinking, but for some reason Rails just never did it for me. Unfortunately the Grails project was undergoing so many API changes as it was working towards the 1.0 release, that it basically rendered the sample application in the book unusable. Through much digging through the documentation and the APIs I was able to struggle through most of the book and knew that this framework had great potential. So now Grails is approaching 1.0 very soon and it’s time to re-familiarize myself with this wonderful platform.

I ran across this post on Rick Hightower’s blog the other day titled Thanks Zed. I have to agree with Rick on many points, especially that Java should stop wasting it’s time with supporting JRuby and instead focus those efforts on Groovy and Grails. Like Rick, I had bought several Rails books and after it was all said and done, I wasn’t really that impressed. I am a huge fan of the whole “Convention Over Configuration” paradigm, but I guess I just wasn’t ready to give up on Java just yet and jump on the Rails bandwagon.

Now as most people will tell you I’m kind of a geek when it comes to Maven. It’s really a nice tool and it makes dependency management in large projects almost a no brainer…almost. The story I’m about to share is true, only the names have been changed to protect the innocent…

Earlier today I had posed a question to a mailing list in the .NET community asking about Continuous Integration with Flex in the .NET world. After a couple of answers from people who obviously did not understand the question, because they just told me to google CruiseControl.NET, someone with some knowledge of TDD and Agile practices stepped up and pointed out the obvious point I was trying to make. There currently is no real good way to automate your FlexUnit tests in such a way that a CI server like CC.NET or HudsonCI would know whether or not all of the tests for your Actionscript classes passed or failed.

This past week I was fortunate enough to attend CodeMash v2.0.0.8 in Sandusky, Ohio. This conference is unlike anything I’ve ever been to, somewhere in the neighborhood of 350 Java programmers, .NET fan-boys and Ruby zealots all under one roof, and even having a little fun together.

Recently I’ve had lots of questions about how to create multi-module projects, so when I discovered this technique, I thought I’d write this up. This technique exploits a little known feature of the archetype:create plugin, and the Maven site archetype to kickstart your project. Creating a multi-module project has many benefits, one of them being the ability to build every artifact in a project with one simple mvn compile command. Another benefit is that if you are using either the maven eclipse:eclipse plugin or the idea:idea plugin, you can enter this command at the root of the project and it will generate all of the project files for all of the contained modules.