One of the basic tenets of agility is to be always in a fast feedback loop. You develop in short iterations (sprints, is you use Scrum). If you believe in Test Driven Development (as I do), you execute tests as frequently as possible.
Accordingly, I believe your development environment must facilitate the capability to redeploy your application in zero time (ok, a few seconds might be bearable). If you have to wait two or three minutes to redeploy your app to see the effect of your last code change, you will be destroying the fast feedback loop, with subtle consequences to your concentration and focus. And you will probably avoid it, getting less and less feedback.
I’ve always been able to create almost instant-redeploy environments in which we did not have to pack jars or wars, and little changes to a class did not force us to redeploy the apps.
However, my last project is a distributed app that includes several wars which share several jars, and so on. When I arrived there, it was taking almost 4 minutes to recompile and redeploy the whole app. Of course, changing a class and expecting the change not to force us to redeploy the app was a dream. Yup!
Besides, I wasn’t able to use the setup I had been using for my last projects: I was caught between a rock and a hard place.
JRebel is a tool that allows instant class redeploy to a jar, war or ear: it just sits there checking whether a .class file is modified, and silently loads it when that happens. And it works. And, it works always! No corner cases of ifs so far.
Configuration is so easy you’ll probably have to configure it just once for the whole project lifetime, and will be able to forget it.
If you are not using JRebel, you are throwing away your time, focus and energy. Seriously: get it!