How often do you redeploy your J2EE application?

The guys at ZeroTurnaround have published an interesting report on the development habits from over 1300 Java developers. One of the questions that really struck me was "how often do you redeploy?"

My answer to this question is "on my development machine, never". I use Jetty which is really easy to embed in a regular application. So all of the projets I work on have this tiny class in their src/run/java directory:

package net.bluxte.project;

import org.eclipse.jetty.server.Server;
import org.eclipse.jetty.server.nio.SelectChannelConnector;
import org.eclipse.jetty.webapp.WebAppContext;

public class StartProject {
    
    public static void main(String[] args) throws Exception {
        Server server = new Server();
        SelectChannelConnector connector = new SelectChannelConnector();
        connector.setHost("127.0.0.1");
        connector.setPort(8888);
        connector.setForwarded(true);
        server.addConnector(connector);
        
        WebAppContext context = new WebAppContext("src/main/webapp", "/");
        context.setClassLoader(Thread.currentThread().getContextClassLoader());
        server.setHandler(context);
        
        server.start();
        server.join();
    }
}

This tiny class allows me to start the server with just a single click on Eclipse's "Run" or "Debug" icons in the toolbar, using the project's classpath where everything is already compiled by the IDE. No need to build a war file, no need to attach to a remote JVM for debugging, no need to wait for long package/deploy/restart operations. And of course code hotswap works just like it should and makes debugging a breeze.

Now the answer "on my development machine, never" is incomplete, and should be added "on the integration server, every time a source file changes" since Hudson picks up any changes, does a full build/test cycle and deploys the new version automatically on a test machine.

Complex "enterprisey" frameworks and specifications have made us forget that things can be simple if you think a bit, and that it also often pays to do a bit of "development design" to increase the developer's productivity without resorting to "helper tools" that only add some bloat to the process.