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
The main tricks here as follows:
- We configure the GWT plugin so that the result of the compilation lands in
target/classes/VAADIN/widgetsetswhich is the location Vaadin uses to locate a
WidgetSetin 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.