It's been awhile since I've blogged. I've been busy with my new job, buying a new house, and preparing for The Spring Experience in December. But before I head to Florida, I've got a couple of No-Fluff/Just-Stuff appearances to make in Dallas and Denver.
I've spoken at several No-Fluff/Just-Stuff events over the past few years and have sat on the expert panel most of the time. One of the questions that is frequently posed to the expert panel is "What is your favorite development tool?". I usually don't have a good answer because aside from Maven, Eclipse and a handful of plugins, I'm somewhat minimalist in my development approach. But today, around the same time that this post goes live, I'm likely to be sitting on an answering that question with 3 new development toys I've been playing with. I'm not saying that these are my favorite tools, but they've certainly caught my attention.
Infinitest
One of the many things that sets an IDE apart from a regular text editor is that any IDE worth its download can tell you immediately if you've made any compile-time mistakes. If you were using a plain text editor to edit your Java code and accidentally fumble-fingered some code, you wouldn't know about it until you ran your build. But if you're using Eclipse, NetBeans, IntelliJ or any other decent IDE, you'll know immediately that when an compiler error is introduced and can take action to correct it.
Unfortunately, no IDE is very good about checking to see if you've introduced an error in your code's behavior. We write unit tests to help ensure that our code behaves a certain way, but we have to wait until we run our test-suite to know whether or not any bugs have been introduced...there's no immediate feedback.
That is, there is no immediate feedback unless you're using Infinitest. Infinitest is a wonderful tool written by Ben Rady that continuously tests your code by monitoring changes and running the tests that are affected by those changes. Assuming that your tests are fast-running, you don't need to wait to find out if the change you just made has broken one or more tests.
I love the idea of Infinitest, but be warned that there are a few wrinkles in using it. Specifically, Infinitest scans your project folder for JARs to include in its classpath. That's great if you're building your application using Ant or some similar tool, because the JARs that your application depends on are probably in a "lib" directory where Infinitest can find them easily. But I use Maven 2 to do my builds and Maven 2 keeps all dependency JARs in a local repository outside of my project directories. Consequently, Infinitest can't find them.
Ideally, I'd like Infinitest to be a plugin in Eclipse that can use my project's classpath as given to it by Eclipse. Failing that, I may have an alternate solution for Maven 2 users. If you use Maven's "dependency" plugin, you can copy all of your application's dependency JARs into target/dependencies by running "mvn dependency:copy-dependencies". It's a bit hokey and non-ideal, but it seems to be a workaround until Infinitest is more Maven friendly. (Hint hint hint...anyone want to submit a change to Ben that makes Infinitest more Maven friendly?)
Pax Runner
I've been preparing for a Spring-OSGi (aka, Spring Dynamic Modules for OSGi) talk that I'll be giving at The Spring Experience and thus have been starting, stopping, loading, and unloading various OSGi containers. Loading an OSGi container with the minimal set of bundles required for Spring-OSGi takes several minutes and requires me to remember all of the bundles each time I do it. And I frequently miss one or two bundles and have to dig around to find them so that I can install them. Let's just say that I find it very cumbersome to load and unload OSGi containers through conventional means and don't enjoy it at all.
Fortunately, I've found Pax Runner, a wonderful bootstrapper for OSGi. Using Pax Runner, I can start and stop Felix, Equinox, or Knopflerfish with ease, preloading it with a set of bundles from a simple list of bundles. What's more Pax Runner can load bundles that are installed in a Maven 2 repository and can optionally use a Maven 2 POM file as its source of dependency information.
Now I have a fool-proof way to load an OSGi container with all of the bundles I need and can setup a new OSGi container in a matter of a couple of minutes!
(BTW, the OPS4J project hosts several interesting OSGi-related projects under the PAX umbrella. If you're tinkering with OSGi, you should check out what they've got at the PAX wiki).
IntelliJ IDEA
I've been an Eclipse bigot for a very long time. Honestly, I don't mind using another IDE, but I've already become quite familiar with Eclipse and don't want to bother retraining myself to use a new IDE. At the same time, I've been hesitant to pay for an IDE (even if it is cheap) when a great free IDE is only a download away.
But I was recently granted a free license to IntelliJ IDEA and decided to try it out. I really don't want to like IDEA, but I gotta say that it isn't that bad. In fact, the one thing that compelled me to add IDEA to this list of my new development toys is that it has great support for Spring built-in. Unlike SpringIDE, the Spring plugin for Eclipse, IntelliJ's bean graphing feature not only shows the relationships between all of my explicitly wired Spring beans, but it is also capable of showing autowired Spring beans! I'm not a big fan of autowiring in Spring because it's not always apparent which beans get wired into which other beans. But that becomes less of a problem if the bean relationships, including autowired relationships, can be presented visually.
So now I have an answer for the NFJS expert panel when I'm asked about tools. Now I just need to formalize my opinion on the JCP, Groovy versus Ruby versus Erlang, and everything else that I'll be asked.
