Give feedback
x
? You're using the old forum. Why aren't you using the new one?
You probably already noticed, we've deployed a new Vaadin-based forum software at vaadin.com/forum. You seem to have chosen to use the old one instead. It's a pity. Why did you choose this old one?
Sharing your thoughts with us will help us fix all bugs and make the new forum a better place for everyone!
« Back to 10. Vaadin 7
Vaadin 7 : Jar Dependencies
Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
Vaadin 7 : Jar Dependencies
Answer (Unmark)
4/4/13 10:59 AM
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.
Attachment

Attachments: vaadin-7.0.3-dependencies.png (187.4k)
RE: Vaadin 7 : Jar Dependencies
Answer (Unmark)
4/4/13 11:27 AM as a reply to Charles Anthony.
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.
RE: Vaadin 7 : Jar Dependencies
Answer (Unmark)
4/4/13 11:49 AM as a reply to Henri Sara.
Thanks Henri : Logged as Documentation Task, Ticket #11484
RE: Vaadin 7 : Jar Dependencies
Answer (Unmark)
4/4/13 12:57 PM as a reply to Charles Anthony.
Hi,

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.
RE: Vaadin 7 : Jar Dependencies
Answer (Unmark)
4/4/13 1:19 PM as a reply to Charles Anthony.
Marko Grönroos:
The graph looks surprisingly familiar, did exactly the same thing couple of months ago to organize the license.html in the installation package.


Spooky!

It's impossible to document the depedencies in the book, as they change too often.

[...]

So, this isn't first a documentation issue, but resolving the dependencies. I hope the Dev team finds some solution.


Cool - I understand that.

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."
RE: Vaadin 7 : Jar Dependencies
Answer (Unmark)
4/4/13 1:50 PM as a reply to Charles Anthony.
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?
RE: Vaadin 7 : Jar Dependencies
Answer (Unmark)
4/4/13 1:53 PM as a reply to Charles Anthony.
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.
Attachment

Attachment

Attachments: ScreenHunter_02 Apr. 04 09.52.gif (13.3k), ScreenHunter_01 Apr. 04 09.51.gif (17.3k)
RE: Vaadin 7 : Jar Dependencies
Answer (Unmark)
4/4/13 2:21 PM as a reply to Charles Anthony.
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)
1
2
3
4
5
<project basedir="." default="resolve" xmlns:ivy="antlib:org.apache.ivy.ant" >   
    <target name="resolve">
        <ivy:retrieve type="jar" pattern="lib/[conf]/[artifact]-[revision].[ext]"/>
    </target>   
</project>
RE: Vaadin 7 : Jar Dependencies
Answer (Unmark)
4/4/13 2:31 PM as a reply to Charles Anthony.
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:

1
2
3
4
    <target name="resolve-build">
        <ivy:retrieve conf="widgetset-compile"
            pattern="buildlib/[type]/[artifact]-[revision].[ext]"/>
    </target>

To get development deployment dependencies:

1
2
3
4
    <target name="resolve-dev">
        <ivy:retrieve conf="default"
            pattern="devlib/[type]/[artifact]-[revision].[ext]"/>
    </target>

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.
RE: Vaadin 7 : Jar Dependencies
Answer (Unmark)
4/4/13 2:36 PM as a reply to Charles Anthony.
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.
RE: Vaadin 7 : Jar Dependencies
Answer (Unmark)
4/4/13 2:48 PM as a reply to Marko Grönroos.
Looks like you found it out while I was typing.
Ha! Thanks Marko!

The biggest problem is the production deployment libraries. t's otherwise the same as the development deployment, but you'd need to exclude the theme compiler and all its dependencies.

I imagine that this be simplified if there was a a separate Ivy configuration for the theme-compiler and it's dependencies...
RE: Vaadin 7 : Jar Dependencies
Answer (Unmark)
11/24/13 10:54 AM as a reply to Charles Anthony.
Henri Sara:
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.
 


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?
RE: Vaadin 7 : Jar Dependencies
Answer (Unmark)
11/24/13 11:06 AM as a reply to Charles Anthony.
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:
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
compile - Compile classpath for source set 'main'.

+--- pchem:core:unspecified
+--- com.vaadin:vaadin-client:7.1.8
|    +--- com.vaadin:vaadin-shared:7.1.8
|    |    \--- com.vaadin:vaadin-shared-deps:1.0.2
|    +--- com.vaadin:vaadin-server:7.1.8
|    |    +--- com.vaadin:vaadin-shared:7.1.8 (*)
|    |    +--- com.vaadin:vaadin-theme-compiler:7.1.8
|    |    |    +--- com.vaadin:vaadin-shared:7.1.8 (*)
|    |    |    +--- org.apache.commons:commons-jexl:2.1.1
|    |    |    |    \--- commons-logging:commons-logging:1.1.1
|    |    |    +--- org.w3c.css:sac:1.3
|    |    |    +--- net.sourceforge.cssparser:cssparser:0.9.5
|    |    |    |    \--- org.w3c.css:sac:1.3
|    |    |    \--- commons-cli:commons-cli:1.2
|    |    \--- org.jsoup:jsoup:1.6.3
|    +--- org.w3c.css:sac:1.3
|    \--- javax.validation:validation-api:1.0.0.GA
+--- com.vaadin:vaadin-server:7.1.8 (*)
\--- javax.servlet:javax.servlet-api:3.0.1