If you are Liferay User and Vaadin Portlet developer, you know that Liferay has Vaadin bundled. If you develop a Vaadin portlet, you should use the bundled Vaadin version, otherwise it'll be a problem after a deployment.

We solved the problem in JVx' VaadinUI by extending Vaadin. Our implementation allows different Vaadin versions independent of Liferay. Some days ago, Matti Tahvonen posted an article about Using "self-contained" approach to package Vaadin portlets. This is an interesting article because it's exactly what we tried to do and we thought that Vaadin developers have a better solution for the problem!

And of course, their solution is better than ours But we are like copy cats and we changed our solution because it reduced code and made it easier for us to maintain our codebase. Our idea was not far away from the recommended solution, but we did too much.

To find out what Vaadin did in their archetype, we followed their posted instructions. We found two steps that could be ignored. The first step was the creation of a custom maven profile because it was possible to add all properties to the pom.xml of the project. The second step was the configuration of the profile in Eclipse. Not needed if properties were added to pom.xml.

And after creating the project, we had the recommended solution and it was absoutely trivial. Simply extend VaadinPortlet, extend VaadinPortletService and override getStaticFileLocation. The created source code:

To be honest... our solution contained a little bit more code but it worked. We've used our new knowledge to improve our solution, because it should be possible to use "self-contained" and "shared" approach without additional source code. We introduced a context parameter to switch between modes. Vaadin could do the same, but currently it's not implemented.

Our new solution is as simple as the original Vaadin source code and the most important thing is that it works with our ant build.