I’m currently looking at starting the migration of our project from Vaadin 6 to Vaadin 7.
We don’t want to use any form of dependency management, so I need to work out what Jars I need when. (Compile time, runtime for development, runtime for production etc)
Is there any clear and simple guide for this - or a simple way of generating it from the ivy/maven config files?
As a starting point for anyone else in the same boat, I used
JBoss’s TattleTale and
GraphViz to generate a dependency graph based on all the jars in the Vaadin 7.0.3 All-in-One archive, which should be embedded/attached to this message.
Not about such tools, but what you need to deploy is typically the following: vaadin-server, vaadin-shared, vaadin-shared-deps, jsoup, a compiled widgetset (vaadin-client-compiled if you don’t have a custom one) and vaadin-themes. I’m not quite certain in which situations sac is used, but IIRC in many cases it is not needed if not using on-the-fly theme compilation nor doing client side debugging. The validation API JAR should also be included if using bean validation and the API is not otherwise on the classpath.
If you are using on-the-fly theme compilation, you also need vaadin-theme-compiler and all its dependencies.
To compile the widgetset or do client side debugging with DevMode/SuperDevMode, you need almost all the JARs in the graph below.
All this could use better documentation in the ZIP package as well as elsewhere.
The graph looks surprisingly familiar,
did exactly the same thing couple of months ago to organize the license.html in the installation package.
It’s impossible to document the depedencies in the book, as they change too often. Especially transient dependencies can change any time, so the right place for any such dependency trees is the Zip installation package.
I actually started writing a section about production deployment, until I noticed that it’s not so trivial to resolve the dependencies. The Ivy depedencies allow separating builds (widgetset-compile) and development runtimes (default configuration), but not production runtimes currently.
It might not even be possible to do with Maven. We use Ivy for the Vaadin library build, and Ivy has configurations that are more flexible than the Maven scopes.
So, this isn’t first a documentation issue, but resolving the dependencies. I hope the Dev team finds some solution.
Perhaps a little background may be useful here : we really don’t want any to use any form of dependency management for our system - I need to be able to have everything needed to build our application (bar a JVM and Ant) in our version control system.
I understand the (basic) idea and problems that Ivy (& Maven) are trying to solve - but fundamentally, I really don’t want to have to care. To use a new version of Vaadin, I want to download everything in one go, stick it in a directory, point the build system at it, and press “go”.
It shouldn’t depend upon an internet connection, or an internal network file system repository; I suspect if I looked at Ivy a little more, I might be able to get it do what I want (?) - but, um, should I have to introduce yet another complexity (from my perspective) into my build/development workflow?
One of the things I loved about starting out with Vaadin 6 was “Here’s a jar file. Stick it in WEB-INF/lib. You’re done.”
I have a related question. I am migrating a project to vaadin 7. Ivy handles putting a bunch of jars in lib/jars and one each in lib/javadocs and lib/sources.
I have one additional 3rd party library. I was getting a NoClassDefFoundError until I put the jar in WEB-INF/lib.
Is this how it’s supposed to work? We are still responsible for manually putting the external jars in WEB-INF/lib?
btw, the 3rd party library shows up in Eclipse Build Path under Web App Libraries but it still needs to be copied manually to WEB-INF/lib. Here are the screen shots.
After a downloading Ivy, a bit of poking around, and almost-randomly hitting the keyboard until something works - the following build file (in the same folder as the ivy.xml module) will parcel up the (jar/class) dependencies of each Ivy configuration, and stick in them in a directory.
It’s a start! I imagine I/we/someone might be able to generate a non-ivy-dependent ant file with appropriate filesets based on the all-in-one download (and/or generate the all-in-one download from the ivy module).
Note that the 7.03 Ivy config stuff hasn’t been added to the Download site (see
my post earlier today )
Perhaps you could still have an Ant script that calls Ivy to retrieve those dependencies, instead of downloading the Zip. And then put the downloaded libs to your repository.
To get build dependencies, you’d need the ivy.xml and ivysettings.xml (as created by the Eclipse plugin) in proper place and have something like:
The biggest problem is the production deployment libraries. It’s otherwise the same as the development deployment, but you’d need to exclude the theme compiler and all its dependencies. I haven’t yet found out how to do that. You’ll also need to compile the theme before deployment and not include the vaadin-themes JAR.
Looks like you found it out while I was typing. Your rule that uses the [conf]
probably works nicer. You may need a separate rule if you need to make exclusions for the production deployment libs.
I am trying 7.1.8 in a project. The above mentioned jars’ sizes approximately:
vaadin-server: 3M
vaadin-shared: 16M
vaadin-shared-deps: 1.7M
vaadin-client-compiled: 2M
It’s around 23M, with dependecies around 30 M. Is not that too high for a webapp that at present merely contains a single user-made classe?
I am using gradle and a nice
gwt-plugin for widgetset compilation. Although it’s easy to separate dependencies this way, the two ones required for java compilation bring transitive dependecies which are not clear if all necessary. This tree is provided by gradle:
Your rule that uses the [conf]