we build a portlet-application which consists of different modules deployed on an OSGI-container (Liferay 7 GA2) using Vaadin-7.7.3.
One of the modules is a self-written Vaadin-Addon.
But with Vaadin-7.7.X release the dependencies of this Add-on (gwt-elemental and gwt-user) are no OSGI-conform jars.
This is probably also noted in the release notes (“OSGi currently does not work with client and client-compiler packages.”).
My question is, whether there is a timeline when this will be fixed?
I might could work arround this problem (at least custom css is possible), but then I’m also limited in the selection of 3rd party Vaadin Add-on’s.
Normally, no client side JARs should be deployed on the server, whether OSGi or something else. Instead, e.g. in a Maven project, they should be marked as “provided” so that they are available at compile time but not included in the deployable WAR, as everything relevant from them is in the form of the compiled widgetset. This also reduces the size of the deployed WAR.
As far as I know, there is nothing in gwt-user that should be needed on the server side. The gwt-servlet JAR contains the corresponding server side classes (with some duplication), and should be used instead of gwt-user as a server side dependency if something from it is needed. I’m not quite sure about its OSGi compatibility status, though.
The gwt-elemental case is a bit more complicated, as it is mostly client side code but contains also a few classes that can be used on either side (JSON implementation comes to mind). If you do use those parts on the server side, note that also the vaadin-shared artifact contains a few of those classes (currently elemental/json/**, elemental/util/Array*, elemental/util/Can* and elemental/util/Map*) with a proper OSGi manifest, so you might not need to depend on gwt-elemental on the server side.
thank you very much for the quick and detailed reply.
I did another try to fix the problem.
You are right, the gwt-elemental is not needed for deployment of the Vaadin-Addon.
I found all required GWT-dependencies in the gwt-servlet JAR.
Unfortunately the JAR ist not OSGI-conform, so I had to extend in manually.
I wondered why the gwt-user and gwt-servlet JAR’s are not OSGI-compatible by themselfs (there are just some additional lines in MANIFEST.MF). Is there a techical cause or are there just not enough people using OSGI-servers?
At the moment the deployment of the Vaadin-Addon fails because I would have to add the vaadin-client.jar module to the OSGI-server which I do not deliver yet.
I’ve installed Vaadin as OSGI-modules in Liferay using Sampsa Sohlman’s com.vaadin.liferay project at github (https://github.com/sammso/com.vaadin.liferay). There the vaadin-client module is not yet included.
But I remembered the problem described in the release notes. The statement there is a bit unspecific. Are I’m going to hit a problem there if I add the vaadin-client module or not?
As far as I can tell, vaadin-client should never be deployed with the application. It is only needed on the computer that compiles the widgetset, not on the server. Thus, the dependency to it should always have the scope “provided” in the POM.
As far as I can tell, the only reason to deploy vaadin-client, vaadin-client-compiler and gwt-user would be if the application actually compiles its widgetset on the fly, which is not supported directly and would require quite a bit of additional work.
As for why gwt-server is not a valid OSGi bundle, the GWT project apparently hasn’t seen that as necessary (probably not that many GWT developers using OSGi) but it should be possible to re-package it as an OSGi bundle as you did.
When I lock throug my code I see, that I import the following classes:
com.vaadin.client.communication.RpcProxy;
com.vaadin.client.communication.StateChangeEvent;
com.vaadin.client.ui.AbstractComponentConnector;
All these are located in vaadin-client.jar. Are they provided by any other vaadin-jar?
(When you create a new project using the Maven archtype “vaadin-archetype-widget” there is a class created called MyComponentConnector, which has these requirements.)
The vaadin-client dependency should be marked to have the scope “provided” in the POM, which makes it available at widgetset compilation time but leaves it out from the WAR (where it is not needed). Those classes are only present in the form of javascript (in the compiled widgetset) in your deployable application.
Some versions of the archetype might have produced the vaadin-client dependency without marking it as “provided” because of an old bug in the Vaadin Maven plug-in, but that should be fixed in more recent versions of the plug-in.