Re-structuring Vaadin package for 6.7

There have been discussion for simplifying Vaadin distribution package for the future releases. I wrote a proposal for a new package structure to
http://dev.vaadin.com/ticket/7381

All feedback would be appreciated.

Hi Joonas,

I would definitely not include sources in the main jar but provide a separate JAR. Linking JAR to sources can be done in IDE (at least in Eclipse) and is automatically managed by m2eclipse. Same for Javadocs.

Also, would it pay to be more modular regarding themes?

Just my two cents.

Regards,

Nicolas

Sources are currently included in vaadin.jar. Removing client-side sources from the package would require introducing quite a lot of new complexity to all places where add-ons are used or gwt compilation needed (eclipse plugin, maven, …).

Size of the sources is about 750kb (17%) of the package size.

Because cost is so little, I would prefer to have “just one jar” simplicity over saving some bits that probably do not matter.

If we would like to provide a smaller jar, we could provide vaadin-stripped-6.7.0.jar that would only contain server-side classes. That package would be about 970kb - thug giving a quite large saving in file-size. Unfortunately use of this package would not be as simple, as one would have to compile client-side and deploy theme separately.

Any proposals?

We currently have the themes separated to modular pieces in svn. They are combined for performance reasons (loading numerous css -files separately slows application down). In my proposal the compromise would be that css is in combined form in the package. Thus patches to css would be made in combined form (requiring hand patching from core dev team for merging patches back to SVN). Reason for compromise - we do not want to complicate bundled build process and distribute css-files twice.

+1 for KEEPING the sources in the main JAR. It’s a huge help and simplification, versus forcing users to find and point to a separate source JAR, and at relatively little cost.

The sources are also easy to strip out for those very few users who absolutely must have the smallest possible JAR.

There was an interesting point about including a build.xml in jar: lowering the bar for building custom versions of Vaadin might encourage use of self-maintained custom version in projects and thus lead to all kinds of problems over the time. This would have two out-comes: 1) headaches for the developers using a self-maintained custom version and 2) invalid bug reports as people would be reporting back bugs that only occur in their own custom version.

Any options on this? Would it be bad to make building custom version simpler? (I know - this is kind of question on whether a state should allow sales of handguns)

Is there way to download full package with everything in ~/eclispe/configuration/com.vaadin.integration.eclipse/download with gwt and vaadin?