You can use the following configuration in your pom.xml to run the GWT compiler when the project is built. By default, the compile goal is configured to be executed during the ''prepare-package'' phase to run as late as possible.
<project> [...] <build> <plugins> [...] <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>gwt-maven-plugin</artifactId> <version>2.8.1</version> <executions> <execution> <configuration> <module>com.mycompany.gwt.Module</module> </configuration> <goals> <goal>compile</goal> </goals> </execution> </executions> </plugin> [...] </plugins> </build> [...] </project>
The module paramter can be used to define a single module in your application. You can also configure compilation for multiple modules by nesting them inside a ''modules'' element. If none is set, the plugin will automagically scan project source and resources directories for ''.gwt.xml'' module files.
You can also force the plugin to compile a module from command line by setting the gwt.module system property.
By default, the GWT compiler is run with WARN logging. If you have compilation issues, you may want it to be more verbose. Simply add a command line option :
-Dgwt.logLevel=[LOGLEVEL]
Where LOGLEVEL can be ERROR, WARN, INFO, TRACE, DEBUG, SPAM, or ALL
The compiler style is set to its default value (OBFUSCATED) to generate compact javascript. You can override this for debugging purpose of the generated javascript by running with command line option :
-Dgwt.style=[PRETTY|DETAILED]
The compiler will output the generated javascript in the project output folder (${project.build.directory}/${project.build.finalName}). For a WAR project, this matches the exploded web application root. You can also configure the plugin to compile in ${basedir}/src/main/webapp that may better match using lightweight development process based on to the "inplace" mode of the war plugin. To enable this, just set the inplace parameter to true.
You may get compilation errors due to OutOfMemoryException or StackOverflowException. The compilation and permutation process used by GWTCompiler is a high memory consumer, with many recursive steps. You can get rid of those errors by setting the JVM parameters used to create the child process where GWT compilation occurs :
<project> [...] <build> <plugins> [...] <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>gwt-maven-plugin</artifactId> <version>2.8.1</version> <executions> <execution> <configuration> <extraJvmArgs>-Xmx512M -Xss1024k</extraJvmArgs> </configuration> <goals> <goal>compile</goal> </goals> </execution> </executions> </plugin> [...] </plugins> </build> [...] </project>
The compile goal is used to run the GWTCompiler and generate the JavaScript application. This mojo can switch beetween to modes : standard or inplace.
Standard uses simple integration of GWTCompiler in the maven build process and will output in the project build directory where the maven-war-plugin is expected to create the exploded web-application before packaging it as a WAR.
Inplace use the web application source directory src/main/webapp as output folder. to match the war:inplace goal. This one setup an explosed WAR structure in the source folder for rapid JEE development without the time-consuming package/deploy/restart cycle.
Using this folder is also very usefull for those of us that run a server using tomcat7:run or jetty:run goals. Those plugins don't require any packaging to launch the webapp, and handle nicely Maven dependencies and classes without requirement for a WEB-INF/lib and WEB-INF/classes. With this default GWTCompiler output directory, the application can be run as is with no packaging requirement.