Running and debugging

To run or debug your client-side code, use the gwt:codeserver goal. This is an aggregator goal, which means its configuration is done in your root POM, not in your gwt-app (in a multi-module setup). This gives the goal the opportunity to use several gwt-app modules from the reactor (which it will do automatically by default).

Note that gwt:codeserver has a slightly different behavior than gwt:compile to accomodate development needs. First, the applications and all modules from the reactor that are depended on with <type>gwt-lib</type> or <classifier>sources</classifier> have their source roots used as-is so that changes can be seen immediately; this means that if anyone of those is declared as a resource directory with filtering or relocation, behavior will be different from gwt:compile. Also, dependencies by default use the runtime scope, whereas gwt:compile uses the compile scope; this allows some differences between gwt:compile and gwt:codeserver classpaths when needed, while working in identical ways most of the time (where dependencies are put in the default compile scope). In any case, that behavior is configurable through the classpathScope property.

Starting with GWT 2.7, you should set the launcherDir property to get recompile on reload. The property should point to a folder that your web server / servlet container will look into for web resources, so that the *.nocache.js file generated by the CodeServer can be loaded by your web browser. You can find sample configuration, in combination with the Tomcat and Jetty Maven Plugins, in the archetypes at https://github.com/tbroyer/gwt-maven-archetypes/. In older versions of GWT, you'd have to resort to bookmarklets from a version of your app that has been compiled (and deployed) once.

Because the goal will trigger the process-classes phase in all modules, it's a good idea to only include client modules in the reactor build using Maven's -pl argument (and don't forget the -am too). If you have several gwt-app modules, limiting the reactor build with only a subset of them will also automatically limit the ones ran through the CodeServer. An alternative is to use the projects property (or -Dgwt.projects= on the command-line), which can be used in profiles for instance to create presets.

The projects property can also be used to run the CodeServer on modules which are not gwt-app (e.g. war). You'd then probably use it in combination with the modules property to define the list of GWT modules to run through the CodeServer. By default, the Maven Plugin for GWT will look for the moduleName property in the projects (whether given explicitly as projects or the discovered gwt-app modules from the reactor build), which gives you an opportunity to configure it even in non-gwt-app projects.

Finally, note that because the CodeServer takes a different set of arguments from the GWT Compiler, you'll have to define some arguments twice: both in compilerArgs for the GWT Compiler, and in codeserverArgs for the CodeServer.