Vaadin 7 Dependencies

Hello,

I am trying to use Vaadin 7 in an OSGI context, so I downloaded the “all in one archive”. The problem is that I was unable to find the exact dependencies between each of the vaadin jars, and the libraries it needs (included in the lib folder). Also, I assume that some of them might be runtime dependencies, so it’s a real challenge to detect all of them. Is there an approach that you could suggest for this, or could you provide some further documentation regarding how these dependencies should be managed?

Thanks in advance

Hi

we are using the following JARs in our OSGI environment:

vaadin-client-compiled-x.x.x.jar
vaadin-server-x.x.x.jar
vaadin-shared-x.x.x.jar
vaadin-shared-deps–x.x.x.jar
vaadin-themes-x.x.x.jar

Thats enough to have vaadin run for us.

Regards,
Alex

The JARs should have OSGi manifests with exported and imported packages listed in them. If there are specific problems with that, please
create a ticket
if there isn’t one for the specific missing dependency.

For the general dependencies between the JARs, see
this thread
.

The proper documentation for what is needed when (in the case of not using a dependency management system) would probably be the ZIP package having separate subdirectories for various purposes.

We are just now looking at Vaadin 7.0.5 – our app and add-on run on Vaadin 6.8.10 now – and the setup is very different.

First, we noted none of the JARs are put in WEB-INF/lib. Will we get problems if we put the Vaadin 7 JARs in there so we have our project and source code repository showing the exact JARs needed for deployment?

We noted that all of the JARs are in squirreled away in a user-specific IVY folder on Windows rather than in our project, so our source code versioning system has no knowledge about what we’re using.

When I did the first test run in Eclipse’s Tomcat, it produced a list of JARs automatically in the WEB-INF/lib (never a good thing in my mind since WEB-INF/lib won’t be auto-updated when we deploy to an actual server). It showed a lot more than just vaadin JARs, making me wonder what exactly is needed when I deploy to a server:

commons-cli-1.2.jar
commons-jexl-2.1.1.jar
commons-logging-1.1.1.jar
cssparser-0.9.5.jar
jsoup-1.6.3.jar
sac-1.3.jar
vaadin-client-7.0.5.jar
vaadin-client-compiled-7.0.5.jar
vaadin-server-7.0.5.jar
vaadin-shared-7.0.5.jar
vaadin-shared-deps-1.0.2.jar
vaadin-theme-compiler-7.0.5.jar
vaadin-themes-7.0.5.jar
validation-api-1.0.0.GA-sources.jar

My impression was that when we go live, I just needed these in a production server:

vaadin-server-7.0.5.jar
vaadin-shared-7.0.5.jar
vaadin-themes-7.0.5.jar

Is that right?

The information is in your source control in the form of the ivy.xml file.

I would strongly recommend sticking to some dependency management system such as Ivy, Maven or Gradle, learning it and configuring it to pick which dependencies to deploy and which ones to use at compile time etc. You can skip Ivy and Maven and just put the files in WEB-INF/lib if you want, but then you need to pay careful attention to what is upgraded when. Use the ZIP download that has all the dependencies and pick from it. Picking the minimal dependencies manually is not really documented.

In addition to what you listed, you also need to deploy at least jsoup, probably vaadin-shared-deps and (only if you don’t have your own widgetset) vaadin-client-compiled. Many of the others are only needed for compiling a theme at runtime (when not in production-mode), but I’m not sure if some are needed also otherwise.

When using a dependency management system, if you have your own widgetset, you can remove the dependency on vaadin-client-compiled. Instead, a compile-time (only) dependency on vaadin-client-compiler is needed.

Vaadin 7.1 has some additional dependencies due to push support.

Thanks, Henri. You may be right, but I disagree that ivy.xml “documents it” when the JARs are not obviously present in the project and checked-in, are retrieved from remote locations that may not be available in the future (or a build that’s not connected to the Internet), and of course could change in the remote locations without regard to our version control.

When I look at the ivy.xml generated when I created a new test project, it lists vaadin-server, vaadin-themes, vaadin-client-compiled, vaadin-client and vaadin-client-compiler (just 5 JARs). I see no mention of how that dependency list differs for dev/compiling versus deployment on a server.

And that list has no mention of 8 of the 14 JARs it produces (listed in prior post). So it’s not particularly obvious how ivy.xml informs me of all the details that are generated (the ivy.xml for widgetset-compile in Eclipse lists 26 JARs!), making it really hard to simply list JARs needed for builds and those for deployment.

Considering I had exactly 1 JAR that I needed to deploy in Vaadin 6, it’s hard to see how this is an improvement.

EDIT: Also, because this is including non-vaadin* JARs, we have to deal with the question of software licensing for the others that aren’t also part of Apache commons that I recognize), like cssparser-0.9.5.jar, jsoup-1.6.3.jar, sac-1.3.jar, validation-api-1.0.0.GA-sources.jar)

The ivy.xml (or Maven pom.xml) documents what your application needs from a logical point of view - the whole point being that their internal dependencies are just that, internal, and you should not need to keep track of them explicitly and manage different dependency version requirements of different libraries etc. by hand. Many libraries used widely nowadays bring with them tens of transitive dependencies and it can be a lot of work to try to keep track of what is really needed for what. That is what dependency management automates.

One of the key principles for Maven repositories is that once an artifact has been released with a (non-snapshot) version number, it will be available forever with that version number and will never change. I know there have been some exceptions (some projects have removed some artifacts that have accidentally contained sensitive information), but those are extremely rare and pretty much never happen for artifacts that are in Maven Central. In practice, all projects (probably numbering in the hundreds of thousands) using Maven/Ivy/Gradle/… around the world rely on this, and the assumption is built deep into Maven and Maven repositories. This also means that once the dependencies for a build have been cached by the dependency management software when performing a complete build, there should not be need for internet connectivity. One could probably even copy the cache from another computer that is connected to the Internet to get all dependencies (including build time dependencies) onto a separate computer.

Ivy confs (in ivy.xml) define what is used for what. The ivy.xml generated by most versions of the Eclipse plugin actually included a little too much in the WAR (vaadin-client and its dependencies), at least the latest Eclipse plugin from the experimental update site generates an ivy.xml that does not do so. You can see the latest version of the ivy.xml template that the Eclipse plugin uses
here
and what changed in it
here
if you want to modify an already created ivy.xml file.

As for licenses, we do maintain a list of licenses of the dependencies and we are careful to only include dependencies whose licenses are compatible with the Apache 2.0 license for the runtime. See the release notes and the license list for more on these.

Some dependencies used only at widgetset compile time might have other licenses but only ones that will not risk exposing your code to the outside or have other problematic effects on the applications you create. If they have any openness clauses, those will only apply to the widgetset compiler code itself and not the application code being compiled. These haven’t really changed much since Vaadin 6 - more or less the same dependencies for widgetset compilation have just been bundled in GWT JARs in the past and not having them separately has occasionally caused version conflicts.

If you want an automated tool for analyzing dependency licenses, managing their upgrades etc. you could look at the commercial offering of
Sonatype
.

I made the changes to my ivy.xml and found it did remove two JARs from the Tomcat webapps’s WEB-INF/lib, though I was surprised that one was the validation-api-1.0.0.GA-sources.jar (seems like other threads indicate this is needed), while it made sense that vaadin-client-7.0.5.jar is no longer included.

For us ivy newbies, is there a simple way to describe how the ivy.xml is converting the dependency entries into a list of JARs (so I can see the maven repos that list the JARs for 7.0.5). It must be contacting a repository URL, etc. that isn’t clear from the xml file alone.

I appreciate your patience and explanations as we adapt to this more complex environment than was needed under Vaadin 6.

Bean Validation API sources are only needed for widgetset compilation. To actually use Bean Validation at runtime, the server (or the WAR) must have the class files for both the API and some implementation but the sources are not needed at runtime.

Although I haven’t tested it, you should be able to get a list of all the dependencies using the
artifactreport
or report ANT tasks.