I recently deployed inadvertently a debug version of our game typrX (typing races at www.typrx.com - try it it\'s fun). It was quickly corrected but I know it may happen again
The idea of using a specific module for debugging has been floating around for some times, and was also mentioned in this Google I/O presentation (see slide 33 from PDF or at 0h31m in the video).
The basic idea is that you have a standard GWT module, and a second debug module that inherits this standard module, configures some properties, and uses GWT's deferred binding to replace some classes with specific instances when debugging.
Then, you only have to configure your Maven / ant build to compile the appropriate module depending on wether you are in development mode or in release mode.
In my project, I did not create an "app.config" deferred binding property, but I might do that later on. What I did was the following:
com/example/MainModule.gwt.xml:
com/example/MainModuleDebug.gwt.xml:
Note: the rename-to attribute is very important here, since you want both modules to be deployed under the exact same name. When you compile during development, you do not want to have to change all your html host pages to point to the debug module.
(...)
(...)
true
(...)
org.codehaus.mojo
gwt-maven-plugin
(...)
com.example.MainModule${gwt.module.suffix}
(...)
gwtDebug
Debug
false
gwtDebug
Simply doing "maven clean install" will compile the production module. In development, you use "mvn clean install -DgwtDebug" to activate the gwtDebug profile, which in turn compiles the debug module.
Of course, you could configure your ~/.m2/settings.xml to always define the "gwtDebug" property...
The same idea would also apply to Ant. But I'm not well versed with it.
When you starts to toy with the idea of overriding your real module with a debug module, you start to envision some very cool possibilities: