Vaadin WidgetSet compilation optimizations

Vaadin is a framework using GWT behind the scene. And for that it needs a WidgetSet, which is basically the definition of the widgets that you want to use on the client-side. If you are using the core widgets of Vaadin, you are good because the vaadin.jar ships with a default WidgetSet for all the core components. However, Vaadin has also a very active community and the Vaadin directory holds hundreds of add-ons. Some of them may require you to compile your own WidgetSet because they have a custom client-side counter part. Or, after all, you might need you own client-side widget which would require you to define a custom WidgetSet as well.

This blog entry is not about explaining how you could define such WidgetSet and build it. The official documentation and this wiki page already explains most of it for Apache Maven. One very annoying issue with this mandatory compilation step is that it is quite slow even on modern hardware and it significantly increate the time of your build. There are several workarounds to this: reduce the number of supported browsers or make sure the result of the compilation can be cached by compiling it in the source directory of your web application project (see this blog post for a complete example).

We also tried to tackle this problem and we thought that if Vaadin can hold the result of the WidgetSet in their jar file, why shouldn’t we? And since a multi-modules build tool is a commodity these days (again, we use Maven but this should work with others too), having an extra module is not really a problem.

Our Vaadin-based projects are composed of several modules describing the different pieces of the application. For very simple project we just have one core module holding all the code that uses the Vaadin API and a webapp project (server module) to package and start the application easily. The core project might use add-ons, in which case we compile the WidgetSet in the webapp project.

Our optimization is about creating another module, depending on core and solely being responsible to compute the WidgetSet. The trick is that module is not active by default so it does not run unless you explicitly ask for it. The result of the compilation is stored in the jar file and can even be shared within the team by deploying a SNAPSHOT to a shared repository. Another nice advantage regarding this technique is that a full project clean no longer requires you to recompile the WidgetSet from your IDE since the project is or can be disabled, depending of the Maven support of your IDE

The following is an excerpt of the Maven pom we used to compile the WidgetSet in a regular jar file

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-jar-plugin</artifactId>
            <configuration>
                <excludes>
                    <exclude>VAADIN/widgetsets/WEB-INF/**</exclude>
                </excludes>
            </configuration>
        </plugin>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>gwt-maven-plugin</artifactId>
            <configuration>
                <extraJvmArgs>-Xmx512M -Xss1024k</extraJvmArgs>
                <webappDirectory>${project.build.outputDirectory}/VAADIN/widgetsets</webappDirectory>
            </configuration>
            <executions>
                <execution>
                    <goals>
                        <goal>resources</goal>
                        <goal>compile</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
        <plugin>
            <groupId>com.vaadin</groupId>
            <artifactId>vaadin-maven-plugin</artifactId>
            <executions>
                <execution>
                    <goals>
                        <goal>update-widgetset</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

The main tricks here as follows:

• We configure the GWT plugin so that the result of the compilation lands in target/classes/VAADIN/widgetsets which is the location Vaadin uses to locate a WidgetSet in the classpath
• We configure the jar plugin to remove extra things that the plugin has generated and we don’t need

Once you are done with this, you only need to add a dependency to this new module in your server module. In order to illustrate these concepts, we have created a showcase on github using the Wizards for Vaadin add-on. This showcase also illustrates a full integration with Maven as well as the use of Cargo to start the container without even the need to install one first.

And, while we were at it, we released a new version of our Embed for Vaadin add-on (see our previous blog post and the release notes).  This add-on allows you to start your Vaadin application right from your IDE. There is one class in the wizard-sample-server that you can use to see how easy this all integrate together.