Blogs

As you might know, Vaadin libraries are bundled in Liferay. This makes it easy to start developing basic Vaadin portlets and you’ll also save in war file size as you are sharing the libraries between your projects. There are also a couple of global Liferay configuration properties (like vaadin.theme) that affect all Vaadin projects deployed on Liferay.

The approach currently used by most tools has some inconveniences though. Practically all your portlet projecs have to use same version of Vaadin and share the set of Vaadin add-ons. When you update one Vaadin portlet, all others should follow.

As a new default way of packaging your Vaadin portlets, you should start using a “self-contained” approach instead. We discussed this yesterday in our joint webinar by James Falkner and Mac Przepióra. In this packaging style each project has its own Vaadin libraries and generated resources packaged into its war file. In addition, each project can configure itself independently of to another and of the global configuration in portal.properties. Now adding add-ons to a project is as easy as in servlet based Vaadin apps and there is a new Vaadin version available, all projects don’t need to be updated at once.

As a downside, the war file size grows a bit and a page with multiple Vaadin portlets from different projects might become slightly slower to load. In case you have lots of small Vaadin portlets, from different portlet projects, and it is essential to optimize the page well, then, and only then, I can still suggest to use the shared library packaging.

The new packaging style is available as a Maven archetype. To prepare for using Liferay IDE with Maven, you’ll need to add a “liferay” profile to your settings.xml For more information about using Maven with Liferay IDE, you can refer to Liferay documentation.

This is the profile I have in mine:

<profiles>        <profile>            <id>liferay</id>            <properties>                <liferayinstall>/Users/youraccount/Applications/liferay-portal-6.2-ce-ga2</liferayinstall>                <plugin.type>portlet</plugin.type>                <liferay.version>6.2.1</liferay.version>                <liferay.maven.plugin.version>6.2.1</liferay.maven.plugin.version>                <liferay.auto.deploy.dir>${liferayinstall}/deploy</liferay.auto.deploy.dir>                <liferay.app.server.deploy.dir>${liferayinstall}/tomcat-7.0.42/webapps</liferay.app.server.deploy.dir>                <liferay.app.server.lib.global.dir>${liferayinstall}/tomcat-7.0.42/lib/ext</liferay.app.server.lib.global.dir>                <liferay.app.server.portal.dir>${liferayinstall}/tomcat-7.0.42/webapps/ROOT</liferay.app.server.portal.dir>            </properties>             </profile>    </profiles> 

The archetype can be found from Maven central with groupId com.vaadin and artifactId vaadin-archetype-liferay-portlet. If you create a project with Eclipse and Liferay IDE, the next step is to configure the project using the previously discussed profile via project properties. Screenshot below shows where to do that.

After that the project should compile fine and Liferay IDE will recognize the project as a Liferay project (so you can also use Liferay Maven plugin goals like liferay:deploy and can edit Liferay deployment files like liferay-plugin-package.properties using Liferay IDE’s graphical forms-based editors).

Relevant Maven build targets:

install will package the project as war under target directory. If a widgetset has changed, this also activates the GWT compiler to build a new widgetset, so it might take a minute or two. E.g. if you add an add-on, like Vaadin Charts, execute this goal after modifying your pom.xml.

liferay:deploy will deploy the war to the liferay instance defined in your settings.xml

clean removes all generated resources like class files and widgetsets.

In case you wish to activate liferay:deploy during install target, you might also wish to configure liferay-maven-plugin with the following configuration.

We’ll most likely change the non-Maven builds to guide towards this kind of packaging style in the near future. Until then, and in case for some reason you cannot start to use Maven builds for your projects, you can create a one project stub using the archetype and then adapt that for your ANT build. I haven’t tried it but I think it should work as well.

The good thing about Maven builds is that it hints your IDE how it should configure the project. If your colleague is a big fan of some other IDE, he can probably just open the project in his IDE and start working. I tested this with NetBeans and it worked flawlessly, and I’d be surprised if it didn’t work in IntelliJ IDEA as well.

Migrating to Vaadin 7

In this post we assume you are using Vaadin 7, but the latest version of Liferay (6.2) includes an older version of Vaadin (Vaadin 6). This isn’t a problem if you use the new vaadin-archetype-liferay-portlet and per-project approach as outlined above. However, if you have many projects that use Vaadin and are looking to optimize your production environment (to minimize the duplication of runtime classes and widgetsets between projects and tosave on JVM resources), you may want to use a single version of Vaadin across all projects (the “global” approach), which requires upgrading the bundled version of Vaadin (6.8) to whatever version you wish to use.

In addition, we are working with Liferay to update the Liferay IDE plugin to support not only creating new Vaadin 7 projects. In the future, new projects should be created in a form of “self-contained” strategy by default, whether they used Maven or not.