Packaging Vaadin


I have a question to the dev team:
Why you need to fork apache-commons to your sub-package, instead to have it upstream? These kind of things makes difficult (if possible at all) to adopt it.
How we can get rid of this external thing?

Generally, when we build RPMs, we need to build them only from the sources, so binary JARs are impossible to have around. Every Linux distribution already have Servlet and Apache commons libraris as a package. So why not use them, instead?

Can it be fixed?


Which Vaadin version are you using?

The forked version was removed from Vaadin in October 2010, as other changes made it unnecessary. I believe Vaadin 6.5 and 6.6 are not using it anymore.

now I am packaging Vaadin 6.6 for our SUSE Linux. Ant’s build.xml still contains paths to jars in many places. Rip them off is a pain, but still much better than have a Maven horrid nonsense. Is there a better build.xml I am missing?

For example
this build.xml from 6.7
contains things like that:

35 <taskdef uri="antlib:net.sf.antcontrib" resource="net/sf/antcontrib/antlib.xml">
36	        <classpath>
37	            <pathelement location="build/lib/ant-contrib-1.0b3.jar" />
38	        </classpath>
39	    </taskdef>

Or this:

42	    <path id="maven-ant-tasks.classpath" path="build/lib/maven-ant-tasks-2.0.10.jar" />

Or this:

141	        <!-- required when compiling WebContent/VAADIN/widgetsets (and also Java server-side classes) -->
142	        <property name="lib-gwt-dev" location="${gwt-dir}/gwt-dev-noservlet.jar" />
143	        <property name="lib-gwt-user" location="${gwt-dir}/gwt-user-noservlet.jar" />
144	        <!-- FIXME: Should use ${gwt-version-dependencies} -->
145	        <property name="lib-gwt-validation" location="${gwt-dir}/validation-api-1.0.0.GA.jar" />
146	        <property name="lib-gwt-validation-src" location="${gwt-dir}/validation-api-1.0.0.GA-sources.jar" />

And so on. This is pretty wrong and pretty nasty if to support Vaadin for a long run. I suggest move this stuff at least to some and define them there. So then we can fix that in our vaadin.spec file. It would be actually perfect if we could use this kind of properties file, so for a usual local build it won’t change anything, but when packaging, spec file can issue commands to redefine jar locations with those, that comes from build requires. And of course, keeping it with Ant is best.

Does it makes sense to you?

Which targets are you running? What artifacts do you need as results?

Most targets should not depend on any resources outside the project, with the exception of testbench-tests, integration-tests, manual and the targets for custom builds or nightly builds (if I remember correctly). I frequently run the widgetset compilation and JAR packaging goals on my workstation without any modifications to my build.xml .

The manual build will probably be split out of Vaadin build in the near future, as will some other parts.

All of these libraries are inside the Vaadin project to keep the project possible to build without separately fetching external libraries etc. that are only needed at build time. The only ones needed after the build are GWT related libraries when compiling your own widgetsets.

I do agree that they could be parametrized, but I don’t really see why you would need to “override” e.g. the Ant tasks as long as they don’t depend on anything outside the project. Also, e.g. the GWT version (and the validation API libraries it depends on) to use with Vaadin is tied to the Vaadin version, so including the relevant JARs does make at least some sense.

Yup. We know that and this is fine.

Because we already providing them with RPM packages and everything should be built from the plain sources. So even things, that are only required to just compile stuff and never actually shipped, we still compiling from the sources. The only exception is Oracle. :slight_smile:

Uhm, we killing them as well and reference them from GWT package instead (during the build). It works already for us. But I am just trying to make it more standard in order to automatically package all the future Vaadin releases.

And one more question: Vaadin wants Servlet 2.3 to catch incompatibilities. But can we disable this and compile with 2.4 at least?

I just checked that all the application servers currently officially supported by Vaadin (at least as of Vaadin 6.6) do support Servlet 2.4, so feel free to disable the check.

One little example why including JAR deps to build a package is a bad idea. Take a look at smart-sprites JAR file. It is compiled with
Google Collections
which is already obsolete and now is called Guava, which we
already packaged
. That makes Java packages depend on obsolete stuff and never get properly updated, which makes its support a nightmare.

Created ticket
for the Ant task libraries, making properties for them. They are a bit of a special case as the normal build properties have not been read when defining these Ant tasks, so using separate properties in the build file for them for now.

Created ticket
for the larger scale changes. If you already have a list of the problematic locations, please comment on them in the ticket.

Note that there are also plans to refactor the project and the build somewhat, possibly in Vaadin 6.7 - certain parts (demos, build of the manual) would be moved out of the main project. The details are still open and the current plan does not directly address many of your issues, but the changes could be coordinated.

I assume you only need the main Vaadin JAR for SUSE, not the additional packages such as the demo WAR.

Perfect. I actually already did it. Where I can contribute an update? It is not that perfect, but at least for a starter now I can generate .properties from the RPM spec properly and then compile whole Vaadin stuff as needed. I still have a trouble with that “Smart Sprites” thing, because this is sort of like a strange alpha version, yet it needs to be packaged as well. As of now we including this JAR into the sources, but it needs to be removed as well shortly. I converted their Maven pom to the Ant, but there are even other dependencies to build Smart Sprites, so it will take a while, until I resolve entire circle. :slight_smile:

Absolutely. All what we need is to properly package according to all the policies required. And as for a runtime Vaadin, which is only one small JAR, we don’t need demo WAR or samples. But to get this little JAR done — there are tons of work required, as you already see… Generally package Java stack is a nightmare, so it would be cool if you, guys, keep it simple and stupid in a future releases, remaining pragmatic, rather then get tempted with Maven automation. The main problem of Maven is that this thing takes JARs from the network and takes it in a binary form. This is absolutely strictly prohibited by any Linux enterprise packaging. So to workaround this, we basically fooling Maven to make it think it is online, but actually offline. Hence we trick Maven and basically it turns to be just a yet another Ant, only with lots of PITA.

Thanks for the help!