The JavaScript compiler is strict, it enforces the use of semi-colons and prevents the use of regexp literals (you must use the RegExp object).

Here is how you should configure the js-compile goal to compile standard JavaScript files located in src/main/js:

<project>
	[...]
	<build>
		<plugins>
			<plugin>
				<groupId>org.zeleos.zwt</groupId>
				<artifactId>zwt-tools</artifactId>
				<version>0.3.1</version>
				<executions>
					<execution>
						<id>compile-js</id>
						<phase>compile</phase>
						<goals>
							<goal>js-compile</goal>
						</goals>
						<configuration>
							
						</configuration>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>
	[...]
</project>

The compiled optimized JavaScript files are then generated by default in the ${project.build.outputDirectory}. Please refer to the js-compile goal documentation for more configuration options.

The ZWT Tools plugin also provides a specific compiler for ZWT JavaScript that enforces the use of the ZWT coding convention

The zjs-compile goal is configured in the same way as the js-compile goal and supports the same configuration options:

<project>
	[...]
	<build>
		<plugins>
			<plugin>
				<groupId>org.zeleos.zwt</groupId>
				<artifactId>zwt-tools</artifactId>
				<version>0.3.1</version>
				<executions>
					<execution>
						<id>compile-zjs</id>
						<phase>compile</phase>
						<goals>
							<goal>zjs-compile</goal>
						</goals>
						<configuration>
							
						</configuration>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>
	[...]
</project>

The ZUIDL compiler is used to generate the resources of a ZWT application from ZUIDL files including the JavaScript files, the CSS files and the HTML file. It also validates that the ZUIDL files are valid.

A typical way to use this plugin includes the generation of all the ZWT applications files but you can also select which files you want to generate.

<project>
	[...]
	<build>
		<plugins>
			<plugin>
				<groupId>org.zeleos.zwt</groupId>
				<artifactId>zwt-tools</artifactId>
				<version>0.3.1</version>
				<executions>
					<execution>
						<id>compile-zuidl</id>
						<phase>generate-resources</phase>
						<goals>
							<goal>zuidl-compile</goal>
						</goals>
						<configuration>
							<apiRelativePath>zwt/api/</apiRelativePath>
							<themesRelativePath>zwt/themes/</themesRelativePath>
							<jsRelativePath>js/</jsRelativePath>
							<jsPackRelativePath>js-pack/</jsPackRelativePath>
							<cssRelativePath>css/</cssRelativePath>
						</configuration>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>
	[...]
</project>

The relative paths are used during the HTML file generation to properly set the paths to the ZWT API and themes or the generated JavaScript and CSS files. Most of the time you would rely on the convention in place and never modify the default values.

Please refer to the zuidl-compile goal documentation for a detailed description of the configuration parameters.

ZWT provides an efficient class loading mechanism which enables developers to properly organize the code of their applications into classes. Although this mechanism is very useful during the development phase, it is not efficient in a live environment. The ZWT packager is used to properly packaged a ZWT JavaScript classes with all its dependencies into one single optimized file.

You need to specify a valid Classpath in order to package all the ZWT Application classes on this Classpath into separate optimized files:

<project>
	[...]
	<build>
		<plugins>
			<plugin>
				<groupId>org.zeleos.zwt</groupId>
				<artifactId>zwt-tools</artifactId>
				<version>0.3.1</version>
				<executions>
					<execution>
						<id>compile-zuidl</id>
						<phase>generate-resources</phase>
						<goals>
							<goal>zuidl-package</goal>
						</goals>
						<configuration>
							<classPath>file://${project.build.directory}/${project.build.finalName}/js</classPath>
						</configuration>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>
	[...]
</project>

The plugin automatically looks for the ZWT API in the Maven dependencies to package it along with the project classes.

It is also possible to specify a list of class to package instead of packaging the ZWT application classes by default:

<project>
	[...]
	<build>
		<plugins>
			<plugin>
				<groupId>org.zeleos.zwt</groupId>
				<artifactId>zwt-tools</artifactId>
				<version>0.3.1</version>
				<executions>
					<execution>
						<id>compile-zuidl</id>
						<phase>generate-resources</phase>
						<goals>
							<goal>zuidl-package</goal>
						</goals>
						<configuration>
							<classPath>file://${project.build.directory}/${project.build.finalName}/js</classPath>
							<classList>org.zeleos.SampleClass</classList>
						</configuration>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>
	[...]
</project>

The previous code will package the org.zeleos.SampleClass located on the specified Classpath in the org.zeleos.SampleClass.js file under ${project.build.directory}/${project.build.finalName}/js-pack/ by default.

Please refer to the zjs-package goal documentation for a detailed description of the configuration parameters.

With the ZWT merging tool, it is possible to apply patches to a given set of ZWT classes. In practice, starting from a ZWT source folder and a ZWT patch folder, the tool will compare files with the same name one by one and append the methods present in the patch file but not in the source, methods present in both the source and the patch file won't be overridden.

This tool is typically used during the development of a ZWT application when classes are regenerated from ZUIDL files in order to include the new callback methods in the *_callback.js files.

<project>
	[...]
	<build>
		<plugins>
			<plugin>
				<groupId>org.zeleos.zwt</groupId>
				<artifactId>zwt-tools</artifactId>
				<version>0.3.1</version>
				<executions>
					<execution>
						<id>compile-zuidl</id>
						<phase>generate-resources</phase>
						<goals>
							<goal>zjs-merge</goal>
						</goals>
						<configuration>
						</configuration>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>
	[...]
</project>

The previous configuration will merge all the *.patch.js files under ${basedir}/src/main/js into the *.js source files under ${basedir}/src/main/js. The resulting files will be also generated in ${basedir}/src/main/js with the *.new.js prefix.