How to create a development/debug and production setup

Question

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

Answer 1

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:

Created a standard module

com/example/MainModule.gwt.xml:

<module rename-to="mainModule">
    <inherits name="com.smartgwt.SmartGwt" />

    <!-- (other configurations) -->

    <!-- gwt-log configuration -->
    <define-property name="log_level" values="OFF,DEBUG" />
    <inherits name="com.allen_sauer.gwt.log.gwt-log-common" />

    <!-- Locales we want to compile for -->
    <extend-property name="locale" values="en" />
    <extend-property name="locale" values="fr_FR" />

</module>

Created a "debug" module, that inherits the standard module and configures some additional properties for development

com/example/MainModuleDebug.gwt.xml:

<module rename-to="mainModule">
    <inherits name="com.example.MainModule" />

    <set-property name="user.agent" value="gecko1_8" />
    <set-property name="locale" value="fr_FR"/>
    <set-property name="log_level" value="DEBUG" />
</module>

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.

Configured Maven and the gwt-maven-plugin to compile the right module

<project>
    (...)
    <properties>
    (...)
    <!--
    Suffix appended to the names of the GWT modules we compile in our child projects.
    Empty by default, this suffix is overriden by some profiles to specify an alternative module to compile.
     -->
    <gwt.module.suffix></gwt.module.suffix>
    <!-- We force GWT-recompilation by default (except when using the "gwtDebug" profile - see below for more info) -->
    <gwt.compiler.force>true</gwt.compiler.force>
    </properties>
    (...)

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>gwt-maven-plugin</artifactId>
    <configuration>
        (...)
        <module>com.example.MainModule${gwt.module.suffix}</module>
    </configuration>
</plugin>

    (...)

    <profiles>
    <!-- This profile should be used during *DEVELOPMENT* -->
        <profile>
            <id>gwtDebug</id>
            <properties>
                <gwt.module.suffix>Debug</gwt.module.suffix>
             <!-- Tells gwt-maven-plugin to recompile GWT modules only when necessary -->
                <gwt.compiler.force>false</gwt.compiler.force>
            </properties>
            <activation>
                <property>
                    <name>gwtDebug</name>
                </property>
            </activation>
        </profile>
    </profiles>
</project>

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:

• You could add performance logs, which would be pruned from the code when in production.
• You could configure all your toString() methods to return something useful when in debug mode, and the empty string when in production (and thus reduce the .js size).
• You may reduce the number of permutations by specifying only one locale / one browser / one log level, to speed up the compilation (but do not forget to test for other locales / browsers from time to time).